Re: [POLICYREP PATCH] Add generic iterators and a list data type to libsepol

[James Antill <jantill@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

On Mon, 2007-04-23 at 17:35 -0400, Karl MacMillan wrote:
> On Mon, 2007-04-23 at 13:52 -0400, Stephen Smalley wrote:

> >   However, looking around, I see you can
> > replace the allocator virtual table with your own functions and there
> > are g_try_* functions that return NULL rather than calling abort.  But
> > not clear that helps with its own internal usage of g_new.
> > 
> 
> This does help internal usage of g_new (verified by code inspection and
> experimentation).

 Errm, What do you mean here? The vtable calls return NULL on failure
_now_ (they just call libc malloc/realloc/free), they only exist so you
can replace them with debugging versions as in g_mem_profile().
 g_new() calls g_malloc() which is defined as calling abort(), via.
g_error(), on allocation failure. Pretty much everything in glib will
break if that changes, for instance g_list_append() calls g_slice_new()
as you add something to the linked list, which calls g_malloc() ... and
g_list_append() has no error path because it knows it can't fail. Dito.
g_hash_table_new_full() on both counts.

>  However, glib includes several custom allocators and
> replacing the allocator vtable did not seem to help there. It might be
> possible to track down all of the allocators and convince them not to
> abort, but there may be problems in the future. We could also try
> catching sigabort but there would be no good way to figure out why the
> abort was delivered. This is really frustrating and is causing people to
> not use glib (the X hackers rejected it over this reason).

 Dealing with the abort() is the simple problem, it's how you then get
out from the call to g_queue_push_fail() when it happens four functions
calls further down the stack ... without dereferencing NULL a few times.

> Any other options (there don't seem to be any obvious ones)? Personally,
> I vote for the C++ STL but that requires a small change to which some
> might object. In summary - C sucks and I'm tired of this 1980s
> programming environment.

 I completely agree, although personally I think C++ sucks more. The
options are pretty sparse, as everyone generally hacks up mediocre
versions of exactly what they need (as everyone is loath to have
externals deps).
 The only other one that comes to mind is NSPR, which is again mostly a
matter of portability with a few other useful things thrown in for good
measure. But I'd be loath to recommend it for libsepol (or much else,
for that matter).
 Of course there are a few million on the internets, of varying quality,
but nothing that's in Fedora that I know of.

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]