On Sat, Apr 07, 2001 at 03:35:08PM -0700, Guy Harris wrote:
> 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.
Oh, right, obviously I am the one who is silly :) Anyway, counting on any
size of a int or long is only asking for trouble. The only portable thing
is to use something as int32 typedefs or something along the line.
BTW: I wonder if there isn't a standard for uint32_t (as used in glibc) or
something like this. Every little tool seems to declare its own
myname_int32 :(
> (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.)
Oh, please, let us not go into such contortions. Instead I would suggest
writing a filter to convert existing dump files. I doubt that anybody
saves such files after interpreting the data though.
> As for the other changes:
>
> [...]
Agreed.
cu
Torsten
PGP signature
