xmalloc string functions

Y

ymuntyan

exit() does NOT write buffers not already given into the stream,
save data local to the functions in the call chain,
lots of other work a clean shutdown has to do.

Depends, doesn't it? You don't have to flush buffers
if you are not writing anything. You don't have to
flush buffers if you are writing a temporary file and
your writer is not going to succeed. Not sure what it
means to "save data local to the functions", but that
may or may not be needed. You certainly don't need to
free() your allocated blocks if your process is going
to die now (it's not a general situation, remember?)

Lots and lots of work is done on clean shutdown, certainly.
Much of that work needs memory too. You can do it?
Great, do it. You can't? Well, you insist on trying
anyway, I am saying it's pointless.
However catching any error (including malloc() fails) is a must.
Yup.



Ah, you means really that you should never check for error but
shorthand exit() when an fopen() fails, a fread() or fwrite() can't do
its job its asced for? Becausae you code gets cluddered on if on that?

No, I didn't mean that.
By that my code is full of fuctions designed to use in that program
only once - because these functions are designed to hide details of
work frm the process through the action.



There is no need to exit() or abort() a failsave app.

Failsafe application? It won't fail, that's true. I don't
think I am talking about failsafe applications though.
You can't draw?
Defere the action until you can do it again.

Good one.
It doesn't matter why you
can't. In some time later you'll be able to do the the job.

Yeah. Hope and you'll get what you need.
You can't
show an error to the user? Hi, your log will show that fact.

What is that log again?
However only the caller or one of its parents in the chain will know
how to handle the failture "no memory" in a usefull way.

BS. Why is it everybody obsessed with "callers" and "parents"?
Sounds like you have no idea about how gui applications work.
There is a
need to unwind the stack until the error can be handled useful. Hey,
only that may give you the needed resources to interact with the user
or other parter your program interacts with.

Yep, main() will get more memory to the toolkit_main_loop()
function.
However when your program comes in a situation where it can't continue
the active action because lack of resorce needed unwind until it is in
the state "nothing done yet" again. Then redo the same thing may end
successfull or fail again. Depending on the current environment there
can be a chance to retry, defere to later or simply shut down clean.
But in any way there is no need to exit() or abort() only because a
resource needed to continue is unavailable yet.

Try harder and you'll succeed! There are no situations where
you should fail! Did I get it right?
At least it doesn't matter if a job can't success because lack of
resource (menory, handles, atoms, or whatever else), important is that
the app gets back to a state it is able to save anything worth to get
saved before it gets lost.

Application shouldn't lose data, absolutely. And? Banana
and apple are fruits. Yep.

Anyway, let me make things easier for you and others,
so you don't have to read what I didn't write.

========================================================
= Wisdom starts here

The only thing an application can do when malloc() fails
is abort(). Any application, in any situation. In fact,
applications should use the following API to be robust
and for user data to be safe:

void *alloc_or_die(size_t n)
{
void *ptr = malloc(n);
if (!ptr)
abort();
return ptr;
}

FILE *fopen_or_die(const char *filename, const char *mode)
{
FILE *file = fopen(filename, mode);
if (!file)
abort();
return file;
}

I got more, but I think you get the idea.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top