Kelsey admits Linux SW is fatally flawed

[Moshe Goldfarb]

Strut on over to comp.lang.c to see our Kelsey in action getting his head
handed to him.

http://groups.google.com/group/comp.lang.c/msg/c3025fff79e1cdde

***************************************************************

Take a look at glib,
http://library.gnome.org/devel/glib/2.14/glib-Memory-Allocation.html

---------Kelsey's reply --------------------


Oh, good God. They didn't. Tell me they didn't.

One wonders how many applications they've screwed over with that bit of
asinine idiocy.

Malcolm should go work for them. He'd love it. "Errors? We don't do
errors, we just crash the app. Enjoy another piece of quality software
from the Gnome team."

***********************************************************

Yes folks make certain to read the entire thread to see the rest join in
and crucify poor old Kelsey.

She must be feeling ill today.

 

[user923005]

Strut on over to comp.lang.c to see our Kelsey in action getting his head
handed to him.

http://groups.google.com/group/comp.lang.c/msg/c3025fff79e1cdde

***************************************************************


---------Kelsey's reply --------------------

Oh, good God.  They didn't.  Tell me they didn't.

One wonders how many applications they've screwed over with that bit of
asinine idiocy.

Malcolm should go work for them.  He'd love it.  "Errors?  We don't do
errors, we just crash the app.  

It doesn't actually crash, it just exits (apparently without any
explanation).

Enjoy another piece of quality software
from the Gnome team."

It does seem to be a bit wanting.

***********************************************************

Yes folks make certain to read the entire thread to see the rest join in
and crucify poor old Kelsey.

She must be feeling ill today.

What?! There is a defect in a software package!
I guess it is not time to panic.
I guess that it may be time to send a defect report.

Besides:

"gnome
(nm) (KEY) , in folklore, tiny subterranean creature associated with
mines and quarries. Usually represented as misshapen, frequently as
hunchbacked, gnomes are said to be guardians of hidden treasures."

See what happens when you don't check your function returns? Or it
could even result in a humorous advertizing campaign.

 

[Moshe Goldfarb]

It doesn't actually crash, it just exits (apparently without any
explanation).


It does seem to be a bit wanting.


What?! There is a defect in a software package!
I guess it is not time to panic.
I guess that it may be time to send a defect report.

Besides:

"gnome
(nm) (KEY) , in folklore, tiny subterranean creature associated with
mines and quarries. Usually represented as misshapen, frequently as
hunchbacked, gnomes are said to be guardians of hidden treasures."

See what happens when you don't check your function returns? Or it
could even result in a humorous advertizing campaign.

It all has to be taken in the context of kelsey.
IOW it's not that their is a flaw in the package.

Google kelsey and you will see what I am saying.

 

[Anonymous]

Strut on over to comp.lang.c to see our Kelsey in action getting his
head handed to him.

http://groups.google.com/group/comp.lang.c/msg/c3025fff79e1cdde

***************************************************************

---------Kelsey's reply --------------------


Oh, good God. They didn't. Tell me they didn't.

One wonders how many applications they've screwed over with that bit of
asinine idiocy.

Well, if you remember that systems overcommit memory anyways, and
therefore mallocs that succeed may not actually have any memory backing
them, this really doesn't make a difference.

 

[Ulrich Eckhardt]

Strut on over to comp.lang.c to see our Kelsey in action getting his head
handed to him.

http://groups.google.com/group/comp.lang.c/msg/c3025fff79e1cdde

***************************************************************

---------Kelsey's reply --------------------


Oh, good God. They didn't. Tell me they didn't.

One wonders how many applications they've screwed over with that bit of
asinine idiocy.

Malcolm should go work for them. He'd love it. "Errors? We don't do
errors, we just crash the app. Enjoy another piece of quality software
from the Gnome team."

***********************************************************

Hmmm, well, he should have read the documentation a bit further, though the
docs themselves could be improved, too. Seems that glib has both failure
modes, aborting and returning NULL. Well done Gnome-project!

Uli

 

[Spoon]

Well, if you remember that systems overcommit memory anyways, and
therefore mallocs that succeed may not actually have any memory backing
them, this really doesn't make a difference.

This feature (memory over-committing) can be disabled.

 

[Kelsey Bjarnason]

[snips]

Hmmm, well, he should have read the documentation a bit further, though
the docs themselves could be improved, too. Seems that glib has both
failure modes, aborting and returning NULL.

I did. I also pondered what this means - that it actually renders the
entire library *less* safe, *less* reliable.

 

[Ulrich Eckhardt]

[snips]

Hmmm, well, he should have read the documentation a bit further, though
the docs themselves could be improved, too. Seems that glib has both
failure modes, aborting and returning NULL.

I did. I also pondered what this means - that it actually renders the
entire library *less* safe, *less* reliable.

Wait a second, I don't get it: to me, xmalloc is a tool. This tool is
appropriate when the only reasonable reaction to OOM is to abort the
program.

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?

Uli

 

[Malcolm McLean]

Wait a second, I don't get it: to me, xmalloc is a tool. This tool is
appropriate when the only reasonable reaction to OOM is to abort the
program.

Not quite. It is appropriate when it wouldn't be reasonable either to
provide an alternative algorithm or to drop the operation without
terminating the program.
The handler is set dynamically, and is repeatedly called until either the
malloc call succeeds, or the handler, not xmalloc(), terminates the program.
The obvious implementation, which I provided for the X windows system, is to
ask the user to close down programs competing for resources.

 

[Ulrich Eckhardt]

Not quite. It is appropriate when it wouldn't be reasonable either to
provide an alternative algorithm

The algorithm is fixed. If you suddenly start musing about changing
algorithms, this discussion about how to allocate memory is useless, sorry.
Surely you can tweak algorithms and structures to require less memory for
the same job, but that is beside the point. Given enough input data and
constrained resources you will always be able to produce an OOM condition.
See, I'm not talking about changing a program's algorithms but the way that
it handles OOM, only that.

or to drop the operation without terminating the program.

You can't drop the operation, because if xmalloc() returned it allocated the
memory. There is no error checking when calling xmalloc(), because it
doesn't have a way to signal errors to the caller.

The handler

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. 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 that guarantee which
allows significant simplifications of some code, anything on top of that is
just the icing on the cake, but basically irrelevant.

is set dynamically, and is repeatedly called until either the
malloc call succeeds, or the handler, not xmalloc(), terminates the
program. The obvious implementation, which I provided for the X windows
system, is to ask the user to close down programs competing for resources.

Interesting, but irrelevant, as I said above.

Uli

 

[Malcolm McLean]

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.

 

[Kelsey Bjarnason]

[snips]

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.

 

[Kelsey Bjarnason]

[snips]

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.

 

[Ulrich Eckhardt]

[snips]

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

 

[Ulrich Eckhardt]

Not enough? Here's another, g_base64_encode.

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

Uli

 

[Kelsey Bjarnason]

...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.