Document number: WG14 N1134
Date: 2005/08/28 
Subject: permit fatals
From: Thomas Plum

At the editing session, I took an action item to write a paper for
Tremblant on the topic "permit fatals".

The editing meeting decided to recommend the term "runtime-constraint"
(with a hyphen) to designate what was previously called "Constraint"
in the TR formerly known as "Safer C Library".  We will state
explicitly that although a runtime-constraint has some features in
common with a constraint, a runtime-constraint differs in significant
ways from a constraint.  (We didn't change the features of the
runtime-constraint, we just changed its name.)

The intent of this cryptic title "permit fatals" is to permit the 
compiler to treat compile-time violations of a runtime-constraint in
the same way that compilers treat violations of syntax rules or
constraints - i.e. a diagnostic shall be issued, and the compiler is
permitted to fail - in other words, the compiler can issue a "fatal
diagnostic".

Here's an example:  strcpy_s(0, 0, 0);

Plenty of runtime-constraints are violated.  We want the compiler to
be permitted to treat this just the same as a wrong number of 
arguments.

The existing rules would permit this iff the compiler's flow-analysis
is strong enough to prove that the erroneous code would definitely
be executed.  But the TR is providing brand-new library functions 
that have not been used in existing code, and our concern for
safety and security is higher than in previous WG14 efforts, so we
propose permitting the compiler to be more strict than previously.

That's why we propose to "permit fatals".

Following up on questions raised during the email discussion:

Concern was raised that we would be re-opening the treatment of
diagnosing undefined behaviors (like x/0 ) that might never be
reached.  However, the runtime-constraint is a new category of
behavior, different from undefined behavior; and we definitely do
not intend to re-open the "unreached undefined behavior" question.

A suggestion was made that in some marketplaces the programmers
will prefer to receive "warning" diagnostics that could be
suppressed via flags or pragmas.  Our response is that we have
no problem permitting such treatments; but the request of this
proposal is that the "fatal" diagnostics also be permitted.
The choice between "warning" and "fatal" can be left to each
implementation.