Date: Wed, 29 May 2013 21:35:49 +0200
On 05/29/2013 09:00 PM, Lawrence Crowl wrote:
> We also need to define the consequences of senseless behavior.
> In many cases, the consequences may be unbounded, which we currently
> call undefined behavior. In other cases, we may limit the actions
> possible for senseless behavior. For instance, we may require the
> implementation to call a no-return handler.
>
> In either event, we must give compilers lattitude to emit diagnostics
> at compile time, at link-time or at run-time. Much of this behavior
> well likely be driven by compiler flags. However, in some cases,
> performance is inconsistent with diagnostics and we must admit
> unbounded consequences. However, unbounded consequences in the
> language definition does not necessarily imply unbounded consequences
> in the compilers. Compilers and programmers need the freedom to
> detect and react to senseless behavior in a manner appropriate to
> the application.
It seems plausible to limit the possible consequences of senseless
behavior in certain cases, along C11 annex L.
Signed integer overflow is a fairly good example here, I believe:
(1) Is a compiler diagnostic acceptable? Yes.
(2) Is a run-time abort acceptable? Yes.
(3) Is an unspecified result value acceptable? Yes.
(4) Is it acceptable that your compiler changes the behavior
of unrelated code that follows the overflow? That's very surprising.
Giving compilers latitude to choose among 1-3 (depending on the
target audience) is fine, but, in my opinion, prohibiting option 4
would be an improvement.
As for mechanics, I'd much prefer to update the standard proper than
have an add-on in the style of annex L. If we need/want something
normative at all.
Thanks,
Jens
> We also need to define the consequences of senseless behavior.
> In many cases, the consequences may be unbounded, which we currently
> call undefined behavior. In other cases, we may limit the actions
> possible for senseless behavior. For instance, we may require the
> implementation to call a no-return handler.
>
> In either event, we must give compilers lattitude to emit diagnostics
> at compile time, at link-time or at run-time. Much of this behavior
> well likely be driven by compiler flags. However, in some cases,
> performance is inconsistent with diagnostics and we must admit
> unbounded consequences. However, unbounded consequences in the
> language definition does not necessarily imply unbounded consequences
> in the compilers. Compilers and programmers need the freedom to
> detect and react to senseless behavior in a manner appropriate to
> the application.
It seems plausible to limit the possible consequences of senseless
behavior in certain cases, along C11 annex L.
Signed integer overflow is a fairly good example here, I believe:
(1) Is a compiler diagnostic acceptable? Yes.
(2) Is a run-time abort acceptable? Yes.
(3) Is an unspecified result value acceptable? Yes.
(4) Is it acceptable that your compiler changes the behavior
of unrelated code that follows the overflow? That's very surprising.
Giving compilers latitude to choose among 1-3 (depending on the
target audience) is fine, but, in my opinion, prohibiting option 4
would be an improvement.
As for mechanics, I'd much prefer to update the standard proper than
have an add-on in the style of annex L. If we need/want something
normative at all.
Thanks,
Jens
Received on 2013-05-29 21:49:34