Ethereal-dev: Re: [Ethereal-dev] patch for packet-smb.c (Locking_AndX)

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 3 Dec 2003 12:39:31 -0800

On Dec 3, 2003, at 2:43 AM, Ronnie Sahlberg wrote:

AFAICS your patch reverses the patch I added to packet-smb.c # 1.366
and changes it back into treating this field as a 64 bit integer in
LittleEndian format.

The reasons I know of for not just supporting 64-bit integral types in Ethereal are

1) not all platforms on which people use Ethereal support them - in particular, Uwe Girlich was using it on some Siemens Nixdorf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HFujitsu Siemens MIPS-based machines whose native C compiler didn't support 64-bit integral types;

2) you can't portably use any of the printf-family routines (or routines that use those routines, such as "proto_tree_add_text()", "proto_add_XXX_format()", "col_add_fstr()", etc.) to print those, because not all platforms on which Ethereal runs support "%ll[doxu]" as the format for that (Windows doesn't, and neither do older BSDs).

1) *might* no longer be an issue, as use of "gint64" and "guint64" unprotected by "#ifdef G_HAVE_GINT64" has crept into the code base, but nobody's complained about it, as far as I know, so either people aren't building Ethereal for those platforms or they're trying to do so, failing, and just giving up. GCC might be available for platforms where the native compiler doesn't support 64-bit integral types, so we *might* want to just bite the bullet and use 64-bit integral types.

2) could probably be made not to be an issue by

having a #define for the appropriate format modifier ("ll" on most platforms, "q" on older BSDs, and I think "L" on Windows with MSVC++);

	using string concatenation with that modifier, e.g.

		"Random 64-bit cookie: 0x016" LONG_LONG_FORMAT "x"

having the configure script determine the right modifier by trying the known ones (or, *IF* there's already a way to get that, e.g. from autoconf or GLib, possibly using that, although that might not be available with older autoconfs or GLibs, and I couldn't find anything obvious in the autoconf documentation for it).

Perhaps if we did that we could change the code to make it more obvious what it's doing.