C++ Logo

sg12

Advanced search

Re: [ub] Diagnosis of implementation limits

From: Matt Austern <austern_at_[hidden]>
Date: Thu, 23 Jan 2014 09:12:59 -0800
On Wed, Jan 22, 2014 at 6:22 PM, David Krauss <david_work_at_[hidden]> wrote:

> Migrating this from the std-discussion list; it’s more appropriate here.
>
> On Thursday, January 23, 2014 9:15:41 AM UTC+8, Richard Smith wrote:
>>
>> On Tue, Jan 7, 2014 at 1:39 AM, David Krauss <pot..._at_[hidden]> wrote:
>>
>>> There are no requirements about what happens when these resource limits
>>> are exceeded.
>>>
>>
>> This is the intent, and is deliberate. If you run your compiler out of
>> memory or stack space, or otherwise exceed its limits in a way which it
>> might not be able to defend against, it is not required to produce a
>> diagnostic.
>>
>
> If a program is abnormally terminated, most environments emit a message
> which counts toward the diagnostic requirement. An OS/shell which doesn't,
> or which allows the stack to overflow into the heap, is unsuitable for
> development work.
>
> Running out of heap space may be diagnosed by the usual means:
> std::bad_alloc, check for null pointer results.
>

There's no guarantee that running out of heap space will give you an
std::bad_alloc. Implementations make an effort to do that, but there are
many reasons why they might not succeed. (Maybe the exception-handling
subsystem itself requires dynamic memory allocation and whatever emergency
reserve the system keeps on hand has been exhausted; maybe instead of a
hard failure from address space exhaustion, the entire machine will page
itself into uselessness.)

Received on 2014-01-23 18:13:01