Wireshark · Ethereal-dev: Re: [Ethereal-dev] Re: rev 15660: /trunk/plugins/asn1/: packet-asn1.c /trunk/epan/: prefs.c range.c

[Guy Harris <gharris@xxxxxxxxx>]

Thomas Steffen wrote:

> Actually, that does not matter. For a project as portable as Ethereal, 
> you need a well defined API to rely on. The C standard library is not 
> nearly well defined enough. POSIX might be nice in theory, but it is 
> neither complete enough nor implemented well enough on most target 
> systems. So you need a runtime environment like nspr, glib or apr.

There are several "portability" issues here.

GLib is currently being used to:

	1) provide missing capabilities on systems (e.g, "g_snprintf()");

	2) mask Windows vs. UN*X differences;

	3) supply capabilities not part of the standard C/OS libraries (e.g., 
hash tables).

> Unless any other API is more suitable, or you define your own, there is 
> no way to get rid of glib.

For 3), I believe the intent *is* to, at least in some cases, "define 
our own" - for example, Ronnie Sahlberg suggests using our own data 
structures, as he suspects GLib's hash tables might not give the best 
performance.

For 2), "defining our own" (as much of the wrapping is just #defines to 
wrap MSVC++ run-time routines such as "_open", "_stat", etc.).

That leaves 1), which, in the case of snprintf(), we handled before by 
providing our own.

>     For one thing, it has the philosophy that memory allocators that abort
>     the program if a memory allocation fails is OK.
>
> For every system with virtual memory, that is a very reasonable 
> approach.

Not if, instead, the program could, for example, close the file it's 
reading at the time, free up memory allocated while reading it, and tell 
the user "sorry, not enough virtual address space to read that file in" 
(or something less technical that gives users advice as to what to do, 
if possible).

> And now the constructive part: say which API should be used. Define on 
> the lowest glib version support. Point to the reference documentation. 
> Say which glib (or C library) calls are not acceptable. And then tell 
> dissector writer to do exactly that.

If we eliminate the use of GLib in the core Ethereal code and 
dissectors, that's exactly what we would do.