> struct pcaprec_hdr maybe should be changed to use a struct timeval
> as defined in timebits.h, like libpcap does. There's a big problem with
> this, though -- traces on 64-bit machines won't be viewable on 32-bit
> machines and vica versa. This seems like a problem with libpcap.
It sure is! It was written, I think, back when "time_t" was 32 bits on
all UNIX platforms - or perhaps when the 64-bit platforms with which
they dealt had 32-bit "time_t" - so it wasn't an issue there, but other
UNIXes have, in anticipation of the Y2.038K problem, gone to 64-bit
"time_t"s on 64-bit platforms.
> Perhaps
> is should be changed so that secs and usecs are always written as 32-bit
> values?
...or 64-bit values, or so that the file header specifies whether the
time stamps have 32-bit or 64-bit values in time stamps.
It's not the only irritation of that sort, either; some platforms
bit-reverse FDDI MAC-layer addresses, and others don't, and there's no
way to tell, from the "libpcap" header, what platform you're on (so
there's a hack in "tcpdump" that checks for Ultrix or something such as
that with a "#define).
We should probably go with the "pcaprec_hdr" change, as it will, at
least, allow captures done on platform XXX to be read on platform XXX,
even if it sacrifices the ability to read captures from some platforms
on some other platforms.
