«

"Ulrich Eckhardt" <> wrote in message
> Stop. There is no handler. I guess you are referring to your own
> implementation that contains a callback which allows the user some control
> of what happens, but that is irrelevant.
>
Fair enough.
>
> AFAICT, the only agreed-on
> semantic of xmalloc() is that it either not returns or returns the
> requested memory, because only with that guarantee you can sensibly
> remove all allocation checks from the calling code.
>
It is relevant because, although the guarantee must necessarily mean that it
is possible for xmalloc() to terminate, this doesn't always imply a sudden
termination with loss of data for each failed call to malloc().

Typically an interactive program runs on a desktop with other programs which
compete with it for memory. So if a small, legitimate request is not
honoured, it is perfectly reasonable to terminate a less-important
competitor.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[snips]

On Fri, 01 Feb 2008 07:46:05 +0100, Ulrich Eckhardt wrote:

> Now, glib offers both allocation functions that return NULL on OOM (the
> 'try' ones) and functions that never return NULL but instead abort, so
> the competent programmer can choose which one is appropriate for his
> job. Where is the problem with that?

Suppose I use glib to develop an application. Glib itself regularly
fails to even document the return of an allocation failure - see almost
any library routine which requires or uses allocations.

As a developer of such an app, I become used to the glib way of doing
things: allocation works, or the app dies.

However, there's now a "don't die, report" allocator. Is it used by the
library itself? If so, there's now problems:

a) The library cannot be relied upon because the documentation, which
assumes "die on failure", does not describe behaviour with the new
allocator, or

b) The library _does_ document functions using the new allocator, but
suddenly the size of the library has doubled (assuming every function now
uses the new allocator) or

c) The library has _not_ doubled, but claims to use the new allocator,
meaning you can expect "silent" changes to at least some of the existing
functions to use the new behaviour, despite all the code written against
the library relying on the old behaviour


In the first case, the library simply becomes unusable - you can't trust
it.

In the second case, the library becomes unwieldy, more prone to bugs
(twice the functions to maintain) and you're never quite sure whether
they actually _did_ use the new allocator everywhere (eg that
glib_function_x() does not, seven call levels down, call the terminate on
failure allocator).

In the third case, all the code you wrote against the library is suspect
and must be re-done - and you don't even know what cases it needs to be
redone for.

Without the report-on-failure allocator, you had a bad design decision,
but it was at least consistently bad.

On Mon, 04 Feb 2008 19:00:17 +0100, Ulrich Eckhardt wrote:

> Kelsey Bjarnason wrote:
>> [snips]
>>
>> On Fri, 01 Feb 2008 07:46:05 +0100, Ulrich Eckhardt wrote:
>>
>>> Now, glib offers both allocation functions that return NULL on OOM
>>> (the 'try' ones) and functions that never return NULL but instead
>>> abort, so the competent programmer can choose which one is appropriate
>>> for his job. Where is the problem with that?
>>
>> Suppose I use glib to develop an application. Glib itself regularly
>> fails to even document the return of an allocation failure - see almost
>> any library routine which requires or uses allocations.
>
> An example would have been nice,

How about string completion? There are several functions there which
allocate memory, yet fail to document behaviour on allocation failure.
For example:

<quote>
GCompletion *g_completion_new (GCompletionFunc func);

Creates a new GCompletion.

func : the function to be called to return the string representing an
item in the GCompletion, or NULL if strings are going to be used as the
GCompletion items.

Returns : the new GCompletion.
</quote>

No mention of what happens on allocation failure. None. Doesn't happen,
ever, apparently.

> I think I get the idea of what some people consider bad about glib now.
> However, I didn't find it in the link the OP was giving.

Not enough? Here's another, g_base64_encode. Here is the total
documentation of the function, on its reference page:

<quote>
g_base64_encode ()

gchar *g_base64_encode(const guchar *data, gsize len);

Encode a sequence of binary data into its Base-64 stringified
representation.

data : the binary data to encode
len : the length of data

Returns : a newly allocated, zero-terminated Base-64 encoded string
representing data. The returned string must be freed with g_free().
</quote>

Returns a newly allocated...string. And it returns _what_ on allocation
failure? Nothing, apparently.


Elsewhere, we discover the nifty concept of GError, which is a mechanism
for handling errors, something akin to an exception. Sounds good.
Here's a comment from the documentation of it:

"Functions that can fail take a return location for a GError as their
last argument."

Oh? g_completion_new doesn't take such a parameter, yet allocates
memory. This means, of course, that every machine g_completion_new will
be used on has infinite memory available - the only way to ensure it
won't fail. Of course, it can, meaning it _is_ a function which can
fail, thus takes a GError as its last parameter. Except it doesn't.
Therefore it cannot fail. Except it can. Error, error, does not
compute...

High comedy at its finest.

Kelsey Bjarnason wrote:
> [snips]
>
> On Fri, 01 Feb 2008 07:46:05 +0100, Ulrich Eckhardt wrote:
>
>> Now, glib offers both allocation functions that return NULL on OOM (the
>> 'try' ones) and functions that never return NULL but instead abort, so
>> the competent programmer can choose which one is appropriate for his
>> job. Where is the problem with that?
>
> Suppose I use glib to develop an application. Glib itself regularly
> fails to even document the return of an allocation failure - see almost
> any library routine which requires or uses allocations.

An example would have been nice, I guess g_error_new would serve as one.
That said, there is no g_error_try_new which would explicitly report OOM by
returning NULL, so assuming a certain consistency I would expect this to
abort. Aborting without a choice is a bad idea though, as is lack of
consistency.

I think I get the idea of what some people consider bad about glib now.
However, I didn't find it in the link the OP was giving.

cheers

Uli

Kelsey Bjarnason wrote:
> On Mon, 04 Feb 2008 19:00:17 +0100, Ulrich Eckhardt wrote:
>> I think I get the idea of what some people consider bad about glib now.
>> However, I didn't find it in the link the OP was giving.
>
> Not enough? Here's another, g_base64_encode.

....which is not documented on the page that the OP's link points to.

Uli

On Fri, 08 Feb 2008 07:43:21 +0100, Ulrich Eckhardt wrote:

> Kelsey Bjarnason wrote:
>> On Mon, 04 Feb 2008 19:00:17 +0100, Ulrich Eckhardt wrote:
>>> I think I get the idea of what some people consider bad about glib
>>> now. However, I didn't find it in the link the OP was giving.
>>
>> Not enough? Here's another, g_base64_encode.
>
> ...which is not documented on the page that the OP's link points to.

It's part of glib, which is the library under discussion, you know, the
library with the design flaw in it.

If browsing the other function references on the site is too difficult,
try google.