Herbert said:
There is no case where a simple exit() will ever the reasonable
ansewer to ENOMEM in production code.
Sorry, but I disagree. Imagine any kind of tool that make a single pass over
some data, like a compiler. Imagine it runs out of memory, what should it
do? Prompting the user to free memory is out, it can't rely on even running
interactively. Yes, it could trigger an internal garbage collection, but
adding one is a significant amount of work and not even that is guaranteed
to help. Maybe it even causes OOM earlier, due to its own overhead. That's
why a compiler, given a too large sourcefile, will simply exit with an
appropriate error. It is not that it's impossible to fix the problem but
that it requires unreasonable amounts of work to do it.
Pleas tell me how to reach variables in auto storage class from an
atexit handler! Tell me how to get acces to variables defined only
in static in function or simply block level.
That is easy, just store them in a global. Did you perhaps miss the 'to some
extent' above? If you are writing to a temporary file, you simply declare
the FILE* global and if it is non-null you clean it up with an atexit()
handler. Simple and efficient.
O.k., then and only then you can be able to write an atexit() handle that
can recover from an out of memory error in all ways regardless of the
numer of threads active, which thread owns which variable and in which
state whatever may be.
Seriously, you are missing the point _COMPLETELY_. xmalloc() is not the holy
grail, it is not the remedy for any code cancer but it is a tool which
competent programmers can decide to use or not use. If it doesn't work for
your code then so be it, but nobody claimed that it should do that. It is
surely not the right tool for a multithreaded server application because
one too large client request would cause DoS for all clients. It would not
be correct to use it in a library, because there it would force the error
handling on the user of the library and thus strongly reduce its
applicability. Nobody claimed that xmalloc() was the solution there.
Oh, I see, you are trained in to have each and any thing in "gobal"
storage because you needs acces to each and any from any poit in any
source module to make the program completely unmaintable.
C'mon, that is just bullshitting here. If you understand why globals can be
dangerous, you would also understand when they can be used without danger
and even to an advantage. Don't construct any arguments on me that I didn't
make.
Uli