Ulf Lamping wrote:
I don't know if Sun Sparc 64 "long"s and/or "int"s are 64bits - if at
least the "long"s are 64 bit it could work.
Solaris on 64-bit SPARC systems, starting with Solaris 7, supports two
programming models - ILP32, with 32-bit longs and pointers, and LP64,
with 64-bit longs and pointers. I think the default model is ILP32,
which builds apps that also run on 32-bit SPARC systems.
I suspect Linux, at least, also supports both of them; if so, I don't
know whether it defaults to ILP32 or LP64.
As of either Solaris 2.5 or Solaris 2.6 (I forget which), 64-bit file
offsets are supported in both programming models, but you need to use
different APIs in ILP32 to be able to handle files > 2GB - for example,
I think you get errors if the file offset goes over 2GB if the file
wasn't opened with the O_LARGEFILE flag. fopen() will *not*, by
default, open with that flag; you need to use fopen64() or build in the
"transitional compilation environment" - see the lfcompile(5) and
lfcompile64(5) man pages.
I don't know what rules other OSes that support large file access in
ILP32 mode have - other than the BSDs (including Mac OS X), where an
off_t is 64 bits even in ILP32 mode, there's no special open flag needed
to support large files, there are "fseeko()" and "ftello()" standard I/O
APIs that take an off_t as a seek pointer argument and return it as a
seek pointer value, and the fpos_t type used in the fsetpos() and
fgetpos() standard I/O APIs happens to be a 64-bit integer (it is *NOT*
guaranteed to be an integral type on all platforms).
zlib uses longs to keep file positions.
...which is an additional problem; it means that only an LP64 version of
zlib can handle files > 2GB, which means that, if you've built Wireshark
to use zlib (to transparently support gzipped files), only an LP64 build
of Wireshark would be able to read or write capture files >2GB.
I didn't changed mergecap (and the other tools) so they might just use
ints to keep file position - which is probably not enough.
Mergecap itself doesn't use file positions at all - it does only
sequential access to files. It uses the merge_ routines to read the
files, and the wtap_dump routines to write the output file.
