On 5 Nov 2012, at 20:55, LZAntal wrote:

>>>>> Fixing STR #2881 (Check image bounds before allocation) requires
>>>>> to check for failed memory allocation. Without exception handling,
>>>>> I believe the only way to do it is:
>>>>> =
>>>> 
>>>>> #include <new>
>>>>> ...
>>>>> array = new(std::nothrow) char[xxx];
>>>>> if (!array) longjmp(xxx, 1);
>>>>> =
>>>> 
>>>>> which violates the CMP because it uses the standard library and
>>>>> the std namespace.
>>>>> =
>>>> 
>>>>> What should we do?
>>>> 
>>>> 
>>>> Can we just use malloc instead of new, then check whether we get a NULL
>>>> pointer or not?
>>> 
>>> Yes, but this would require to rewrite the deallocating code to use
>>> free() instead of delete, and make sure every possible instance is
>>> changed.
>> 
>> 
>> Ah, ok...
>> 
>> I don't think we should throw an exception, so if here's no other way to 
>> prevent new from throwing the exception, I guess we are forced down this 
>> route?
>> 
>> Anybody…?
> 
> Could we just do a temporary allocation with malloc() and check if it worked, 
> if so free it and use new on it.
> We did this many years ago to load assets. Probably there is a "modern" 
> approach to this by now I am still a little rusty with c++


No, you get a race, or at least the possibility of a race, on any modern (i.e 
multi-threaded, multi-core) CPU, so the fact that "malloc" succeeded does not 
mean that "new" will too, even if called just after you free the malloc.

And of course, "new" may try to allocate more memory than malloc, since it will 
probably be storing additional meta-data about the object just allocated that 
malloc doesn't bother with...

So, in practice, "probing" the heap with malloc would probably work most of the 
time, right up until it doesn't and the whole thing blows up.

If it is the case that "new" wants to throw the exception (I just do not know 
if that is the case!) then maybe we do need to use the std lib calls to 
suppress that behaviour?






_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to