[llvm-dev] GEP with a null pointer base

[Peter Lawrence via llvm-dev]

Paul,
         The proposition under discussion is this

Deleting UB, rather than warning about UB, should not be the default,
as this is contrary to the essentially universal software engineering
practice of writing software that is compiler warning free, static
analyzer warning free, and dynamic analyzer warning free.

This is based on the assumption that in order for llvm to be useful to its
users it should mitigate rather than exacerbate the problems inherent
in the language w.r.t. UB.

No one is debating in this thread what the standard does or should say.

After suggesting that the user should have an opt-in option for deleting
UB it was suggested that this would be awkward to implement in llvm.
I disagree, but it seems that the burden of proof falls on me, so in the
fullness of time I will do this. (In particular I believe there should be a
UBCE pass, just like there is a DCE pass).


Peter Lawrence.





> On Aug 2, 2017, at 6:29 AM, Robinson, Paul <paul.robinson at sony.com> wrote:
> 
>> Saying “The C++ language lets me assume that that won’t happen, &
>> optimize on that basis” is an assumption that that’s what the user
>> wants, but you haven’t asked you’ve just assumed, and AFAICT it is an
>> incorrect assumption.
> 
> Well, by using C++, the programmer agrees that the rules of the language
> apply to their program, and the rules of the language say that the
> compiler can do whatever it likes.  So whether the user wants it or not,
> that's what they have effectively agreed to.
> 
>  undefined behavior
>  behavior for which this International Standard imposes no requirements
>  [ Note: Undefined behavior may be expected when this International
>  Standard omits any explicit definition of behavior or when a program
>  uses an erroneous construct or erroneous data. Permissible undefined
>  behavior ranges from ignoring the situation completely with
>  unpredictable results, to behaving during translation or program
>  execution in a documented manner characteristic of the environment
>  (with or without the issuance of a diagnostic message), to terminating
>  a translation or execution (with the issuance of a diagnostic message).
>  Many erroneous program constructs do not engender undefined behavior;
>  they are required to be diagnosed.
>  —end note ]
> 
> If you want to argue that it is *more useful* to the programmer to have
> diagnostics for undefined behavior as represented in their source code,
> I expect you would get essentially universal agreement.  But what I am 
> understanding from this thread is an argument that it's a *requirement* 
> to diagnose UB, and that is just not what the language requires, and 
> consequently not what the user is entitled to.
> 
> If I'm misunderstanding, I'd love to be corrected.
> Thanks,
> --paulr