> I'm not getting the replies to my post about large files, but I just
> checked the archive. Yes, I'm talking about log files greater than 2
> GB.
Then "pcap-dlpi.c" is, as Bill Fenner noted, irrelevant; the code in
question is not reading from a log file, it's reading from the kernel
address space of a machine running HP-UX 9.x, and HP-UX 9.x doesn't run
on PA-RISC 2.0 machines and thus wouldn't support a kernel address
bigger than 4GB at the most, and probably doesn't even support that.
> We often have argus (carter bullard's util) files just over that
> barrier. In any case, using an int instead of ssize_t isn't
> technically correct because they may be different (as in this case).
However, if they're different, it would only matter if the return value
of "read()" *in that routine* didn't fit in an "int", and "int"s are 32
bits on HP-UX on PA-RISC, and, as Bill Fenner noted, the only way you'll
get back a return value that doesn't fit in 32 bits is if the byte count
passed to "read()" doesn't fit in 32 bits, and, as per the note about
HP-UX 9.x in the previous paragraph, you're not going to get anything
out of the kernel's address space that takes more than 2GB - heck, the
chances that you'll get anything that takes even *close* to 2GB are
somewhere in the closed interval between "slim" and "none" (I say
"closed interval" because I strongly suspect the chances are, indeed,
"none").
So, whilst it might be technically correct to use "ssize_t" - which,
BTW, is "int" on Solaris 2.6, *even though 2.6 supports files >2GB*,
because 2.6 doesn't support 64-bit mode on SPARC V9, so a single object
can't be bigger than 2GB, and I suspect it's going to be 32 bits on a
number of other 32-bit platforms with large file support - in that code,
doing so isn't going to make any difference whatsoever to the ability of
libpcap or any of the applications that use it to handle capture files
bigger than 2GB.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
