PHWinfo - Afficher un message

04/02/2008, 12h32

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.

04/02/2008, 12h32	#13
Kelsey Bjarnason Messages: n/a Hébergeur:	Re: Kelsey admits Linux SW is fatally flawed 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.