On Jan 24, 2014, at 7:54 AM, Lawrence Crowl <Lawrence_at_[hidden]> wrote:

> On 1/23/14, Matt Austern <austern_at_[hidden]> wrote:
>> On Wed, Jan 22, 2014, David Krauss <david_work_at_[hidden]> wrote:
>>> 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.

Just to be clear, I only intended to say that compile-time diagnosis is always reasonable, if only a message noting abnormal termination of the compiler itself. (What would a “diagnostic message” look like on a deployment target with no output device whatsoever?)

In embedded development, you might build on a limited target system which can barely support a compiler, but in such situations you often have another compiler from the vendor on hand as well. I think such marginal, target-hosted compilers can reasonably be deemed noncompliant if truly quiet failure is a possible behavior. Users can get some assurance from the corresponding desktop implementation, and in any case such a setup is genuinely unreliable. (Also, this sort of application doesn’t seem to much concern new revisions of C++.)

>> 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?

I don’t want this to turn into a discussion about robust applications.

Yes, if you send the compiler into an endless loop, or the OS halts it due to memory overcommitment, there may be no diagnostic. Perhaps there should be an additional provision that the translation process may fail to terminate upon exceeding a limit.

But UB means a defective executable may be produced, and implementations tend to do better than that, because it’s what customers demand. The standard should formalize the practice of reporting excessive recursion.

Background: I was researching N3882, which proposes an implementation-defined maximum number of lines in a source file, as reported by __LINE__. No implementation currently diagnoses such overflow. Currently there is a specific (but widely flouted) requirement that #line directives not overflow. It seems misguided to specify such a half-measure over such a minor issue, but on the other hand most similar limits are already diagnosed without any requirement in place.