Re: xmalloc string functions

[snips]

On Mon, 04 Feb 2008 22:23:29 +0100, Richard wrote:

That *you* cannot conceive of cases where allocation failure may not be
fatal isn't relevant: others can.

You seem to miss the point. I can. But they rarely happen

Really? I'm sure you'll back this up with data from a wide-scale formal
research project analyzing that very question, right? Right?

Somehow I suspect you're blowing smoke out your backside, but I'm willing
to be wrong there - just show me the study.

That said, common, rare or occasional really doesn't make arse all
difference. The fact is allocations _can_ fail. A good - read
"competent" - programmer realizes this and deals with it. Deals with it,
ideally, in a manner which is something more than simply saying "I'm too
freakin' lazy to write error handling code, so abort."

and the fact
that YOU fail to see the fact that you made an arse of yourself by not
reading the documentation properly is not my issue.

Sorry, I did read the documentation. You know, *both* parts about
allocation, which cause it to involve a contradiction, as well as other
parts which clearly rest on the use of _one_ of the conflicting methods.

Sorry, which part didn't I read correctly?

I still have some sympathy for NOT checking all mallocs in certain
situations. It matters not about other processes when ones own can not
malloc 32 bytes.

I have no idea where you get this 32 bytes crap from. Xmalloc and glib
fail just as handily on 32KB or 32MB as on 32 bytes. Maybe you've never
needed to allocate anything more than 32 bytes at a time; others have.

What have YOU contributed to OSS that gives you the right to rubbish
such people as the Gnome development team?

What has being an OSS developer got to do with anything? Is there some
magic which prevents anyone but OSS coders writing decent code, or being
able to recognize design flaws?

One of life's sureties is that there's generally a reason for most
things.

I'm sure there are. Yet thus far, the only actual "reason" offered for
this design decision has been sheer laziness - that it's just too hard,
too messy, too ugly, to write error handling code. Yeah, well, nobody
said programming was easy.

It is easy to criticise. not so easy to build a project, in your free
time, like Gnome and QT etc.

I don't recall anyone saying it was easy. I do, however, see you
apparently trying to justify a _bad_ decision based, again, on nothing
more than laziness.

Maybe the Gnome developers *did* have some legitimate reason for doing
what they did. Let's stipulate that for the moment. Why, then, can
those defending the design - you, for example - come up with no defence
for it other than laziness?

Pretty sad, if that's the best reason for it.

.

Relevant Pages

  • Re: Signs of Deliberate Artifact?
    ... The argument from design was demolished more than 200 years ago: ... Here's Kant arguing against the teleological argument for the existence ... and human reason can never do without ... that is, the nature of different things could never spontaneously, by ...
    (talk.origins)
  • Re: OT - Cant we all agree????
    ... The reason is that so many decent, honorable, ... I've observed your thoughtful and measured responses to Powell over ... Jeff is who he is. ... Is he the most important design engineer in the ...
    (rec.music.classical.recordings)
  • Re: OT - Cant we all agree????
    ... posters, why is it that I keep wandering into threads which they have ... The reason is that so many decent, honorable, ... I've observed your thoughtful and measured responses to Powell over ... Is he the most important design engineer in the ...
    (rec.music.classical.recordings)
  • Re: OpenVMS Seminar in Toronto (2005-02-24) a few points
    ... > of the alpha systems, except the DS15, were essentially completely ... > designed before the HP-Compaq merger. ... > engineers did not have access to the design specs from the other group. ... that others have good reason to feel differently about. ...
    (comp.os.vms)
  • Re: Quad Core PC for less than a Mac Mini
    ... All the design work is done by the MB and case manufacturers. ... only a dual core on this page, no CPU for this motherboad can be ... Because *all* of the CPU options for this motherboard suck. ... So your answer is you're just bending over backwards to find a reason ...
    (comp.sys.mac.advocacy)