> On Jan 15, 2022, at 4:28 PM, Martin Sebor <mse...@gmail.com> wrote:
>
> On 1/14/22 07:58, Paul Koning via Gcc wrote:
>>> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc <gcc@gcc.gnu.org> wrote:
>>>
>>>> ...
>>> But right now that's equivalent to making it observable,
>>> because we don't have any other terms than observable or
>>> undefined. As aluded to later you would have to
>>> introduce a new concept, something pseudo-observable,
>>> which you then started doing. So, see below.
>> I find it really hard to view this notion of doing work for UB with any
>> favor. The way I see it is that a program having UB is synonymous with
>> "defective program" and for the compiler to do extra work for these doesn't
>> make much sense to me.
>
> This is also the official position of the C committee on record,
> but it's one that's now being challenged.
>
>> If the issue is specifically the handling of overflow traps, perhaps a
>> better answer would be to argue for language changes that manage such events
>> explicitly rather than having them be undefined behavior. Another (similar)
>> option might be to choose a language in which this is done. (Is Ada such a
>> language? I don't remember.)
>
> A change to the language standard is only feasible if it doesn't
> overly constrain existing implementations.
I was thinking that if a new feature is involved, rather than a new definition
of behavior for existing code, it wouldn't be a constraint on existing
implementations (in the sense of "what the compiler does for existing code
written to the current rules"). In other words, suppose there was a concept of
"trapping operations" that could be enabled by some new mechanism in the
program text. If you use that, then you're asking the compiler to do more work
and your code may get slower or bigger. But if you don't, the existing rules
apply and nothing bad happens (other than that the compiler is somewhat larger
and more complex due to the support for both cases).
paul
