Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Kelsey admits Linux SW is fatally flawed

Reply
Thread Tools

Kelsey admits Linux SW is fatally flawed

 
 
Moshe Goldfarb
Guest
Posts: n/a
 
      01-29-2008
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....025fff79e1cdde

************************************************** *************
> Take a look at glib,
> http://library.gnome.org/devel/glib/...llocation.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.
 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      01-29-2008
On Jan 28, 4:15*pm, Moshe Goldfarb <(E-Mail Removed)> 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....025fff79e1cdde
>
> ************************************************** *************
>
> > Take a look at glib,
> >http://library.gnome.org/devel/glib/...llocation.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.
 
Reply With Quote
 
 
 
 
Moshe Goldfarb
Guest
Posts: n/a
 
      01-29-2008
On Mon, 28 Jan 2008 18:34:36 -0800 (PST), user923005 wrote:

> On Jan 28, 4:15*pm, Moshe Goldfarb <(E-Mail Removed)> 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....025fff79e1cdde
>>
>> ************************************************** *************
>>
>>> Take a look at glib,
>>>http://library.gnome.org/devel/glib/...llocation.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.
 
Reply With Quote
 
Anonymous
Guest
Posts: n/a
 
      01-30-2008
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....025fff79e1cdde
>
> ************************************************** *************
>> Take a look at glib,
>> http://library.gnome.org/devel/glib/...llocation.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.
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-30-2008
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....025fff79e1cdde
>
> ************************************************** *************
>> Take a look at glib,
>> http://library.gnome.org/devel/glib/...llocation.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

 
Reply With Quote
 
Spoon
Guest
Posts: n/a
 
      01-30-2008
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.
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      01-31-2008
[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.

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      02-01-2008
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

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-01-2008

"Ulrich Eckhardt" <(E-Mail Removed)> 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

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      02-02-2008
Malcolm McLean wrote:
> "Ulrich Eckhardt" <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LDO admits that linux will never make it as a desktop OS Squiggle NZ Computing 3 10-23-2010 08:12 PM
Olympus admits their micro 4/3rds focusing system is flawed RichA Digital Photography 10 03-29-2010 08:23 AM
Linux Torvalds admits he is not father of Linux steve NZ Computing 0 05-18-2004 03:04 AM
Linux Torvalds admits he is not father of Linux steve NZ Computing 0 05-18-2004 03:01 AM
MSDN Examples flawed Stamen Gortchev ASP .Net 11 09-29-2003 08:34 AM



Advertisments