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 builds. > 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 stack. Anyway, the above is just a quick thought, which I didn't think through very extensively. -- Giel
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzoneemail@example.com https://mail.gna.org/listinfo/warzone-dev