Re: xmalloc string functions
- From: ymuntyan@xxxxxxxxx
- Date: Thu, 31 Jan 2008 14:47:37 -0800 (PST)
On Jan 31, 2:26 pm, "Herbert Rosenau" <os2...@xxxxxxxxxxxxx> wrote:
On Tue, 29 Jan 2008 08:12:51 UTC, ymunt...@xxxxxxxxx wrote:
There is nothing to recover because failure of fopen()
is a normal situation. Absolutely different from a failure
of malloc() when you are trying to allocate a structure
to push into the event queue to scroll text a bit later.
There is no difference at all. When I can't open a file I will tell my
caller that fact like I do when malloc() fails to delever me the
amount of memory I ask it for.
The caller will check the error condition it receives and will react
properly on that and then tell its caller the the error when it is
unable himself to recover from that error to continue as it should
when possible. Its caller does the same until there is a point that is
either
- action is complete undone - clean state
normal work goes on
- action is complete undone - no chance to to contine normal run
shut down program cleanly - a restart of the progam may be more
successfull
There is nothing that requires an abort() or exit() abnormally.
What exactly are you talking about here? If you do shut down
the program then you do shut it down, that's it. Whether you
do it up the stack in the main() or in the memory allocator
may or may not be different. If it's not different, then it
1) doesn't make much sense to unwind the stack;
2) actually is more expensive to unwind the stack: the more
code the more bugs you got.
Where it's not true, it's not true.
Sure, it costs a bit more to get a program failsave - but it saves
lots of money, lots of time and holds customer because no customer
will ever complain because the program aborts, looses or destroy work
or data only because the programmer was crazy enough to kill its
program only because there was a moment where an open() faild, there
was for a period of time not enough memory to allocate a small big or
very big amount of memory to get a single action done.
It makes always sense to check malloc() for success - because this
saves a lot of money for useless maintenance, earning annouyed
customers, ending up in loosing trust.
Right, malloc() result must always be checked. Except it doesn't
imply your code must be cluttered with if() for every call to
whatever_func_you_use_to_allocate_memory().
Though if all your application does is fopen(),
then you can safely abort() when fopen() fails.
Or, you could try and determine why it failed, and take corrective
action, either automatically, or at the user's direction. But hey,
that cuts into the Xbox360 time, eh?
Strawman you see. We were talking about malloc() and
you tell my application will crash when fopen() fails.
Note that if your application can ask user about something,
then it does more than fopen(). If it can take any
action when fopen() fails, then it does more. That's
what I meant. cat utility doesn't have much to do
if it can't open the file it's supposed to read.
A gui application doesn't have much to do if it
doesn't have memory to draw stuff it draws.
This is completely false. Even a guy application can handle any lack
of memory well without the need to crash the whole app.
Right, it can. Except it can't draw if it doesn't have
memory to draw. I don't care if the application is still
up if it doesn't display the stuff it's supposed to display.
Nor do I care how it exits on OOM, using abort() or exit(0)
or exit(EXIT_FAILURE); does it exit from main() after everything
properly returned an error or right in the draw_thingie()
call (AFTER it properly cleaned up its crap, how about that?).
Yevgen
.
- Follow-Ups:
- Re: xmalloc string functions
- From: Herbert Rosenau
- Re: xmalloc string functions
- Prev by Date: Re: My solution to allocating memory
- Next by Date: Re: translating oo features to C
- Previous by thread: Re: xmalloc string functions
- Next by thread: Re: xmalloc string functions
- Index(es):
Relevant Pages
|
|
