On 1/23/14, Matt Austern <austern_at_[hidden]> wrote:
> On Wed, Jan 22, 2014, David Krauss <david_work_at_[hidden]> wrote:
>> Migrating this from the std-discussion list; it’s more appropriate
>> here.
>>
>> On Thursday, January 23, 2014, Richard Smith wrote:
>>> On Tue, Jan 7, 2014, 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.

I've developed on many systems that do not have those guarantees.
We should not be concerned so much development as with deployment,
because problems get larger or machines get smaller when progrems
get deployed.

>> 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.)

Following up, getting an application to respond well to resource
exhaustion is a harder task than getting the programming system to
report exaustion. So, the question I have is how does one program
systems to be robust to resource exhaustion and what should the
language do to help that?

-- 
Lawrence Crowl