Possible bug in util/iobuf.c:iobuf_open on Solaris

[Bodo Moeller]

Matthias Urlichs <smurf at noris.net>
> Bodo Moeller:

>> Try "gpg < madrid-root.ufs.pgp > whatever" so that gpg will not have
>> to open the file.  For accessing large files in 32-bit programs,
>> Solaris has a proprietary set of function calls (open64, access64

> It's not proprietary, it's standardized. GNU libc does the same thing.

Is there really a standard on this?  I wouldn't think so (and wouldn't
hope so); Sun calls this a "transitional compilation environment".
Source code that throughout uses "off64_t lseek64(..., off64_t, ...)"
and all the rest of them in addition to "off_t lseek(..., off_t, ...)"
(with tons if #ifdefs, presumably) wouldn't look very nice.

An alternative is to the large file compilation environment where
64-bit types are automatically used.  This, however, violates
the current C standard, so programs must be verified if they
still work with this.

Another solution, obviously, is to compile the program as a 64-bit
program (if the OS allows 64-bit programs).

> Ideally, gpg should be compiled with large-file support. Under GNU libc,
> the set "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
> is sufficient; I don't know the flag set for the Solaris headers.

On Solaris, "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" should be
used for the large file compilation environment, and "-D_LARGEFILE64_SOURCE"
for the transitional compilation environment (the latter is enabled
by default, but if you define _POSIX_SOURCE or _XOPEN_SOURCE
you have to tell the header files that you accept those additional
prototypes anyway).  These compilation flags can be obtained
from getconf(1), this presumably is preferred to using fixed parameters:

     $ getconf LFS64_CFLAGS
     -D_LARGEFILE64_SOURCE
     $ getconf LFS64_LDFLAGS
     
     $ getconf LFS64_LIBS
     
     $ getconf LFS64_LINTFLAGS
     -D_LARGEFILE64_SOURCE
     $ getconf LFS_CFLAGS
     -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
     $ getconf LFS_LDFLAGS
     
     $ getconf LFS_LIBS
     
     $ getconf LFS_LINTFLAGS
     -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
     

>> etc.); I think it should work with I/O redirection because then
>> for gpg it's just like being used in a pipe.

> If it's implemented correctly in the Solaris kernel, it _won't_ work.

> That's intentional. Heated discussions have been taken place between the
> "make it work, and don't care if some tools fail" and the "we have to do
> this the safe way" people. The latter camp won.

Why shouldn't it work in a pipe?  Of course the 32-bit version of 
tell(3) must not treat stdin as a regular file if it is too large.