Kelsey admits Linux SW is fatally flawed

Discussion in 'C Programming' started by Moshe Goldfarb, Jan 29, 2008.

  1. 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.
     
    Moshe Goldfarb, Jan 29, 2008
    #1
    1. Advertising

  2. Moshe Goldfarb

    user923005 Guest

    On Jan 28, 4:15 pm, Moshe Goldfarb <> wrote:
    > 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.  


    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.
     
    user923005, Jan 29, 2008
    #2
    1. Advertising

  3. On Mon, 28 Jan 2008 18:34:36 -0800 (PST), user923005 wrote:

    > On Jan 28, 4:15 pm, Moshe Goldfarb <> wrote:
    >> 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.  

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


    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.
     
    Moshe Goldfarb, Jan 29, 2008
    #3
  4. Moshe Goldfarb

    Anonymous Guest

    On Mon, 28 Jan 2008 19:15:23 -0500, Moshe Goldfarb wrote:

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


    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.
     
    Anonymous, Jan 30, 2008
    #4
  5. Moshe Goldfarb wrote:
    > 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."
    >
    > ***********************************************************


    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
     
    Ulrich Eckhardt, Jan 30, 2008
    #5
  6. Moshe Goldfarb

    Spoon Guest

    Anonymous wrote:

    > 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.
     
    Spoon, Jan 30, 2008
    #6
  7. [snips]

    On Wed, 30 Jan 2008 07:44:28 +0100, Ulrich Eckhardt wrote:

    > 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.
     
    Kelsey Bjarnason, Jan 31, 2008
    #7
  8. Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Wed, 30 Jan 2008 07:44:28 +0100, Ulrich Eckhardt wrote:
    >
    >> 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
     
    Ulrich Eckhardt, Feb 1, 2008
    #8
  9. "Ulrich Eckhardt" <> wrote in message
    > 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.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Feb 1, 2008
    #9
  10. Malcolm McLean wrote:
    > "Ulrich Eckhardt" <> wrote in message
    >> 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


    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
     
    Ulrich Eckhardt, Feb 2, 2008
    #10
  11. "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
     
    Malcolm McLean, Feb 2, 2008
    #11
  12. [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.
     
    Kelsey Bjarnason, Feb 3, 2008
    #12
  13. 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, Feb 4, 2008
    #13
  14. 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
     
    Ulrich Eckhardt, Feb 4, 2008
    #14
  15. 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
     
    Ulrich Eckhardt, Feb 8, 2008
    #15
  16. 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.
     
    Kelsey Bjarnason, Feb 9, 2008
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stamen Gortchev

    MSDN Examples flawed

    Stamen Gortchev, Sep 25, 2003, in forum: ASP .Net
    Replies:
    11
    Views:
    566
    Stamen Gortchev
    Sep 29, 2003
  2. =?Utf-8?B?YnN0b2RkYXJ0?=

    Flawed logic

    =?Utf-8?B?YnN0b2RkYXJ0?=, Jul 31, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    736
    S. Justin Gengo
    Aug 2, 2004
  3. clintonG
    Replies:
    9
    Views:
    513
    clintonG
    Sep 5, 2005
  4. stax
    Replies:
    45
    Views:
    1,326
    Oliver Wong
    Feb 10, 2006
  5. Roshan
    Replies:
    5
    Views:
    565
Loading...

Share This Page