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.
_______________________________________________
Wireshark-users mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-users

Reply via email to