Ethereal-dev: Re: [ethereal-dev] Re: IPv6 enhancement for ethereal 0.5.1

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: guy@xxxxxxxxxx (Guy Harris)
Date: Mon, 8 Mar 1999 21:13:28 -0800 (PST)
> 	I've placed a patch which is less OS-header dependent.
> 	ftp://ftp.kame.net/pub/kame/misc/

It still depends on "u_int8_t", "u_int16_t", "u_int32_t", and
"u_int64_t" being defined.  Not all OSes define those (for example, the
traditional BSD versions didn't have the underscore after the "u").

The first three could be replaced by "guint8", "guint16", and "guint32";
however, "u_int64_t" is trickier, as it requires a compiler that can
handle 64-bit integral types - GLib doesn't, as far as I know, require
that, and doesn't define any "guint64" type.

I suspect most modern UNIX C compilers support "long long int" and
"unsigned long long int" as 64-bit types (yes, even on 64-bit platforms;
at least on Digital UNIX/Alpha, "long long" is 64 bits, not 128 bits),
so *if* we're willing to restrict Ethereal to platforms that can handle
64-bit integral data types, and if we construct an autoconf macro to
figure out whether to use "long long" or "long" (or whatever other
variants show up), we can handle "u_int64_t".