On Mon, 9 Aug 1999, Laurent Deniel wrote:
> John Heffner wrote:
> >
> > Redhat 6 (glibc 2.1) uses a time_t (long int) for the struct timeval
> > members.
> >
> > In redhat 6, libpcap is exacly as you describe below, full of 64-bit bugs.
>
> That's the first OS that I know which uses 64 bits for struct timeval
> fields, even Tru64 UNIX/alpha uses 32 bits.
The original change was in the Linux 2.2.x kernel, I beleive (possibly in
the 2.1.x kernel). I'm not sure why they did this. The other changes
seem to have been in response.
> > I think the best thing to to is fix libpcap to correctly handle any length
> > int, by defining macros SWAP16, SWAP32, and SWAP64, and just do a sizeof
> > check to see which one should be used.
>
> No, to correctly handle that problem at libpcap level, a modification
> of the file format (and so version) is required. So IMHO this is a bad
> idea. It's simpler to force the use of 32 bits timestamps in libpcap.
This makes sense; however, every application that uses libpcap must be
careful to define its own timeval structure that has 32-bit ints, instead
of using the one defined in the system headers.
> > As to my previous comment about not using 64-bit values for timestamps so
> > that other architechtures could read file generated on 64-bit
> > architectures, I was completely wrong. This stuf is full of
> > arch-dependent stuff anyway.
>
> Which ones ? libpcap file format is quite portable.
Sorry, my mistake. I misread some stuff. I guess I was right to begin
with.
-John
