Reply to thread

Message: [QUOTE="Paul Hsieh, post: 2382747"] I'll go with the "it depends answers" that others have posted. Fundamentally you have to decide on an error policy for your program, then just follow it. What? There is no way you can predict the size of the straw that breaks the camel's back. This is also a system/platform assumption that is quite possibly incorrect. Certain "poor heap architectures" such as the one used in the original UNIX platform (and which apparently SCO still uses) can accumlate "lost blocks" -- meaning that any successive random sequence of allocations regardless of size will eventually exhaust the heap. Another possibility is that in a multi-process system you are unable to move the sbrk() pointer because some application has grabbed the system memory allocation lock in some way. Huh? My (cheapo) system doesn't do that. How do you know this? If the function is its own culprit, but it strictly observes error codes, then freeing its resources and simply returning with an error code may be sufficient to completely recover the main program, simply with no valid result from the leaf function. For example, if you are writing a bignum math calculator on a 32 bit system, and an end user asks it to perform Factorial(100663296), its likely to run out of memory in the process of trying to compute this. If you simply free the memory used and issue some kind of error message, it can continue with other computations without exiting (which could be tragic, if there was a long sequence of unsaved work for example.) [/QUOTE]

Verification