Dennis Schridde schreef:
> Am Sonntag, 24. August 2008 23:12:18 schrieb Dennis Schridde:
>> Am Sonntag, 24. August 2008 22:55:48 schrieb Per Inge Mathisen:
>>> On Sun, Aug 24, 2008 at 5:42 PM, Giel van Schijndel <[EMAIL PROTECTED]> 
>>> wrote:
>>>>  * Change an ASSERT that checks calloc's return value into an if()
>>>> block (we can also run out of memory on non-debug builds...)
>>> I am also rather mystified by this. When we fail to allocate memory
>>> and do not handle it gently, the next thing that happens is inevitably
>>> a crash when the null pointer is accessed. There is no reason to
>>> ensure that a crash happens with a call to abort() - if we are not
>>> going to attempt recovery, we just need to ensure that something is
>>> written to the log in order to debug it. Adding a five line
>>> conditional to every memory allocation is rather pointless and just
>>> bloats the code.
>> *Maybe* a real crash can corrupt something or is not always handled
>> correctly?
>> Aside of that I think we could add a out-of-memory "handler", or some more
>> generic way of handling the most common errors.
>> Why? So we can inform the user in a nicer manner than "application X was
>> terminated in an unusual way". (Console output now, maybe error popup
>> windows later.)
> IRC-update, rather generic:
> - Program "defensively", which means try to recover from errors (i.e. 
> out-of-memory situations).

Hmm, the "program defefensively" I've learned to know means "try to
*detect* and handle every/most errors" it doesn't mean recovering from
them. That's just a terminology issue though, so don't interpret that
last sentence as an attempt to start a flamewar.

That aside, I do agree that for some kinds of errors we should try to
recover. That's a design issue though (i.e. "higher abstraction" than
the code itself). So we'll need to decide on some kind of project wide
strategy for certain kinds of errors in certain cases. E.g. "out of
memory while loading maps" -> "notify user and fall back to main menu".

> - Only assert there, not abort, so that a debug build will catch the error, 
> but a release build can continue.

The only reason I added that particular piece of code there is because
that currently is the most consistently used strategy employed during
memory allocations. So that strategy is currently our *implicit* memory
allocation-error handling strategy (as an *implicit* design strategy).
Thus we need some strategy of memory handling.

> - Only do explicit handling of "extreme" situations (like out-of-memory) in 
> certain situations which are particularly vulnerable.

"particularly vulnerable", ..., sorry that's rather vague. Especially
since every single case where *alloc() returns NULL it *will* cause a
crash if we don't handle it. There's also the thing of detecting out of
memory when it occurs. I personally prefer that at the very least we
*always* check the return value of memory allocation functions and print
out a log message (e.g. "Out of memory"). If that has to go by means of
an ASSERT I'm fine with it.

NOTE: ASSERT prints a debug message both on debug as well as non-debug

> An example was:
> out-of-memory on map load
> -> present a popup box "sorry, could not load map because we ran out of 
> memory" and return to mainmenu.
> Game start and map load were considered particularly interesting for such 
> out-of-memory handling.

Map load sounds reasonable to me, but if by game start you mean
application startup (i.e. from main()), then I think we *should* bail
out. As we need a lot more memory past the main menu than in it.

As for non-recoverable memory allocation errors. I do agree it would be
nice if at the least we could get a message across to the user about it.
But I don't want all code to be cluttered with GUI message calls, etc.
So I was thinking that we could use some exception-like system to jump
to a point higher up the stack where we've got a handler for certain
types of errors (out-of-mem being one of them). setjmp() and longjmp()
seem like they might do the trick. The only problem with this, though,
is that all code that allocates memory and wishes to use this system to
notify the users of errors, is that that code has to be further down the

Anyway, the above is just a quick thought, which I didn't think through
very extensively.


Attachment: signature.asc
Description: OpenPGP digital signature

Warzone-dev mailing list

Reply via email to