Ethereal-dev: Re: [ethereal-dev] Problem with packet-stat.c

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 18 Nov 1999 13:57:53 -0800 (PST)
Well, there were a pile that were due to GLib or GTK+ having figured out
that the compiler it was using was GCC, and therefore that certain GCC
extensions were usable, and using them in its header files.  (For
example, "g_assert()" uses a GCC extension if available.)

I only cleaned up one of the signed vs. unsigned warnings - many of them
are due, ultimately, to the fact that, as I remember, the PDP-11 MOVB
instruction sign-extended when moving into a register, causing "char" to
be signed in PDP-11 C; if you use unsigned chars in order to keep the
sign extension from happening on platforms that follow in the PDP-11's
footsteps, you may get a lot of those complaints, and I'm not sure
peppering the code with casts is the right answer.  I don't think those
type mismatches will prevent compilation on many platforms (if any), and
many of them don't represent real problems.

I cleaned up a few of the remaining problems; what remains are:

	1) a problem in the init-routine-registering code I checked in
	   recently - ANSI C allows function pointers and "void *"s not
	   to be interconvertible, and, so as not to gratuitously anger
	   the Gods of Architectural Diversity, I'll probably convert
	   that code not to use GSLists;

	2) use of "inline" in "packet-rsvp.c" - I guess we haven't yet
	   had anybody complain about their compiler rejecting "inline",
	   but it may happen at some point.

Some C extensions to avoid in the future (or to, at least, protect by
not using them on platforms that don't have them):

	inline;

	zero-length arrays;

	commas after the last element of an enum;

	C++-style comments;

	semicolons after the closing "}" of a function.

The three in the middle have all, as I remember, caused problems on
IBM's C compiler for AIX.  The first and last apparently haven't, but
the latter, at least, can probably easily be avoided (the former may be
a bit more work to avoid if you don't want procedure calls; macros can
do it sometimes, but can't necessarily always do it).

There may be other extensions we've (intentionally or unintentionally)
used, and that have caused problems, as well.