Jonas Maebe wrote: > > On 22 May 2005, at 20:07, Konstantin Münning wrote: > >> When you skip the check and allocate always then the program will >> crash anyway when there is not enough memory. > > No. Either you catch exceptions resulting from a lack of memory and > recover, and then you have the same checking as before, except that the > check happens atomically (by the OS: you ask for more memory and if > there is no more memory, you get an exception).
It seems you are missing a "small" point. Compatibility. With BP7 there are no exceptions - if you try to allocate more memory than availible you get a runtime error. This runtime error can't be switched off like IO-errors. OK, there are the exit procedures, but there is no recover. The structure of a program is completely different when designing it to work with exceptions and recovering from these. At least for the affected parts. All the "old" code needs to be redesigned in a way it would work ONLY with the new compiler. OK, there are the IFDEF's, but for most cases it isn't worth the effort. Last but not least - exception handlers can still be added to deal with the tiny chance that the problem occurs - no need to change the "original" code. > Another possibility to set the global system unit variable > ReturnNilIfGrowHeapFails to true, and then you can check after each > allocation whether the resulting pointer is nil (if so, not enough > memory was available) or not. That's easier than exceptions but unfortunately also an incompatible way. I don't think MaxAvail is so bad that everyone must be enforced to stop using it and is not left to choose by himself. I think most programmers now would either omit the check expecting the program to fail on low memory anyway or they would write a replacement function to avoid work and by this keeping the flaw you are so afraid of. Some will avoid switching to the new compiler and only a few with impotrtant code which have not yet done it better would consider doing a major rewrite. I'm sorry, but I still prefer keeping the compatibility and adding a warning (with hints) so anyone can do it better. Of course you are right that this might be a bug source under the specific circumstances but please don't try to enforce it the community. Otherwise great compiler :-). Konstantin. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel