On Sat, Sep 7, 2013 at 2:46 PM, Mike Stump <mikest...@comcast.net> wrote:
>
> On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis <g...@integrable-solutions.net>
> wrote:
>
>> On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
>>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>>
>>>> On Sep 7, 2013, at 3:33 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
>>>>>
>>>>> this patch teaches the compiler that operator new, when it can throw,
>>>>> isn't allowed to return a null pointer.
>>>>
>>>>
>>>> You sure:
>>>>
>>>> @item -fcheck-new
>>>> @opindex fcheck-new
>>>> Check that the pointer returned by @code{operator new} is non-null
>>>> before attempting to modify the storage allocated. This check is
>>>> normally unnecessary because the C++ standard specifies that
>>>> @code{operator new} only returns @code{0} if it is declared
>>>> @samp{throw()}, in which case the compiler always checks the
>>>> return value even without this option. In all other cases, when
>>>> @code{operator new} has a non-empty exception specification, memory
>>>> exhaustion is signalled by throwing @code{std::bad_alloc}. See also
>>>> @samp{new (nothrow)}.
>>>>
>>>> ?
>>>
>>>
>>> Thanks, I didn't know that option. But it doesn't do the same.
>>
>> Indeed.
>
> Can this throw:
>
> void *operator new (long unsigned int s) {
> return 0;
> }
>
> ? Is this allowed to return 0?
If that is supposed to be a definition for the global function 'operator new',
then it fails the requirement of the C++ standards since 1998.
-- Gaby
