On Sat, Apr 07, 2001 at 07:28:54PM +0200, Torsten Landschoff wrote:
> That's silly. Exchanging int for long reverses the problem. The result is a
> fine binary on alpha and nowhere else.
On platforms with 32-bit ints and longs, replacing int with long, as hsi
patch did, doesn't make any difference, so his change doesn't break
non-Alpha (or, rather, non-64-bit) platforms.
> Anyway, current libpcap and tcpdump
> don't have this issue anymore, right?
The only real issue, as far as I know, is the per-packet header using
"struct timeval", the size of the elements of which is
platform-dependent; Assar Westerlund fixed that a while ago, by
defining, in "pcap-int.h", a "pcap_timeval" structure, both of whose
elements are "bpf_int32" values, and a "pcap_sf_pkthdr" structure, used
as the layout of the per-packet header in savefiles, using a
"pcap_timeval" as the time stamp. That's in the 0.5[.x] releases, as
well as the 0.6[.x] releases.
(This means that our libpcap can't read captures from older versions of
libpcap on systems with 64-bit values in "struct timeval"; if that's a
problem, we could probably throw in some heuristics to try to detect
64-bit values in time stamps, but I'd prefer not to do that until
somebody complains.)
Assar didn't change "struct pcap_header", which means applications that
print timestamps *don't* have to override the native timeval, as Mark
had to do because he changed "struct pcap_header". (Not changing
"struct pcap_header" also means that *binary* compatibility isn't
broken.)
As for the other changes:
the change to "newchunk()" shouldn't be necessary - in fact,
making that change could, I think, cause "newchunk()" to return
structures not aligned on 8-byte boundaries on ILP64 platforms,
which runs the risk of causing misaligned-reference faults;
changing a cast to "(long)" to a cast to "(int)" in a call to
"gen_cmp()" shouldn't make a difference, as "gen_cmp()" has a
prototype in scope (in fact, given that it *does* have a
prototype in scope, the casts shouldn't even be necessary);
changing the types of the fields in "struct pcap_md" shouldn't
be necessary - all it does is makes the counters overflow on
64-bit-"long" platforms at the same point that they'd overflow
on 32-bit-"long" platforms;
changing the argument to SIOCGSTAMP isn't necessary in our code,
as we use "struct timeval" in "struct pcap_header";
casting a pointer to "int" rather than "long" when checking the
bottom 2 bits, to see whether it's 4-byte aligned, shouldn't
make any difference.
-
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
