Re: xmalloc string functions

[snips]

On Tue, 29 Jan 2008 00:25:48 -0800, ymuntyan wrote:

node = malloc( sizeof( *node ) );
if ( node == NULL )
{
blah}

else
{
list_append( list, node );
blah

}

Golly, how unbearably painful.

Oh yes. Easy. How many lines of code is that?

Just about exactly the number required to handle the error without doing
something as abysmally bad as killing the application, tossing the user's
data, simply because you're too freaking lazy to write code to handle the
allocation failure.

And how many lines of code
will you get if you do it ten times?

Depends on the structure of the code, now don't it?

Huh? A segfault is a result, generally, of one of two things: a
runaway pointer, or an allocation failure - you know, the very thing
we're suggesting you actually design your code to test for.

I'm saying that you got so many possible segfault places that you won't
test the one where it will actually segfault.

I see. It's better to simply kill the app and lose the data, than to
write error handling code which _might_ fail. Yes, I see. Given the
choice between no protection and some, you prefer none. Got it. And you
think this is sane, do you?

But hey, it's not like data matters, right? Who cares, data's
worthless, just crash the app.

Okay, okay. After we crashed the application and lost user data,

No, that's *your* asinine approach. I prefer apps written by people who
actually give a damn about the data.

let's
talk about that old boring main loop. Who is it going to report errors
to?

What *are* you babbling about?

After we failed to process an event in the user code, user code
returns an error to the events dispatcher. What does that do?

No idea. If it's built to your standards, it probably kills the app
because it couldn't put a "mouse moved" notification into the queue.

Could be either. Point is, we know that _real world_ applications
_are_ dying from this design principle, which means that while today
it's "only a browser", there's no telling what it will be tomorrow.

Err, if an application eats too much memory

"Too much" according to whom? You? Some random spec nobody outside the
Gnome world has ever seen? Process limits?

doesn't work for it. It's the application bug if it eats too much memory
and dies.

Ah, I see. It's a *bug* if the app eats too much memory and dies. Hmm,
wait a second... that's *exactly* what glib does on allocation failures -
causes the app to die. Yes, we're agreed, it's a bug. A stupendously
bad one which should never have seen the light of day.

I'm glad we're in agreement. Of course, the proper thing to do there is
*not* to abort, but to return a notification of allocation failure. I'm
sure you'll report this to the Gnome team.

No, it's the same story. Application tried to allocate something,
couldn't, *died* and took the data with it. Depending on the app - and
the data - this would be grounds for anything from simply pulling hair
out to actually hunting down the developer with a baseball bat. Or a
lawyer.

So don't lose data?

Right. Which means do *NOT* use retarded libraries like Malcolm's
xmalloc, or glib, which insists upon aborting the app on allocation
failure.

You can avoid losing data with glib, yes.

Really? Good. Please explain how, when one of the glib allocation
functions, the ones which _abort the app_ on failure, allow for a
sensible data save on exit. You know, data which may be strewn about in
variables visible only to the functions they're defined in, that sort of
thing.


Just
please stop talking this stuff about losing data.

As soon as this nonsense about aborting the app on allocation stops being
included in code, I'll stop talking about losing data. Let me know when
glib is fixed to work in a sane and safe manner.

"So what" is that my data wasn't hooped by your brain-dead strategy of
simply aborting on error, that's what. I know you don't think users'
data actually *means* anything, but I can assure you, the *user* thinks
it does.

Sorry, I didn't say lose data.

Take another look. Says right there in the docs, the app is aborted.
You know, *aborted*. Doesn't even get a returned NULL or other indicator
which would indicate "something wrong, save your data", it just gets
summarily nuked.

Yes, you did say "lose data".

.

Relevant Pages

  • Re: ASP.NET Authentication
    ... The process hosting the web app must have at least read ACLs for the web ... I have to log into the server to see a more enlightening message than "Runtime error" and then being directed to change the customErrors mode to off to view the specific error message. ... to start monitoring file changes" blah, blah, blah. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: VB Application Wont Run on Other Machine
    ... You say the VB.net app was a conversion from a previously existing VB6 ... it seems to me it's an installation problem. ... blah, blah). ...
    (microsoft.public.dotnet.languages.vb)
  • Re: xmalloc string functions
    ... It's better to simply kill the app and lose the data, ... talk about that old boring main loop. ... void *ptr; ...
    (comp.lang.c)
  • Refresh fields by code - specifically {INCLUDEPICTURE}
    ... The app then makes a DataDoc.doc (with boring things like PartName, ... blah blah) and includes the image-path-name, ... If I stop the formletter document before printing - I see the one picture ... How can you refresh INCLUDEPICTURE by using code. ...
    (microsoft.public.word.mailmerge.fields)
  • Re: Crawl SS - Mac version problem
    ... aborting" ... How are you running the app? ... right because the working directory will likely be set to something ... If you're looking for a better terminal emulator than Terminal.app ...
    (rec.games.roguelike.misc)