Re: undefined-behavior obstack.c:139

[Bruno Haible]

Paul Eggert wrote:
> The bad citizen here is clang, not Gnulib or Coreutils. Or maybe it's 
> the C standard; it doesn't matter. Clang needn't (and doesn't) complain 
> about every violation of the C standard, and it should not be 
> complaining about this one.

I would be willing to
  1) open a bug report with the Clang ASAN people, asking them to move
     the   (char *) NULL + 0   detection to a separate, "pedantic"
     category.

But this would not be enough. Marc has pointed us to
  https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-In-Action/
example 2, which highlights that compiler writers exploit undefined behaviour
knowledge in order to strengthen optimizations. The same kind of optimization
is possible here: When a compiler sees
   <pointer> + <integer>
it can, by ISO C 23, deduce that the <pointer> is non-NULL. 

We would thus also need to
  2) ask the clang people whether they can promise that they will never make
     this optimization,
  3) ask the GCC people the same thing.

Do you think there's a chance they will say "yes, we promise"? I don't think
so. Rather they will probably say "interesting, here's another possible
optimization; let's use it!".

> > It's like with other changes we saw in the past:
> >    - strict aliasing rules - forbid to cast (int**) to (char**) etc.
> >    - signed integer overflow.
> > What was once a common style is now outlawed.
> 
> It's not like those changes, because those other changes were put in for 
> good reasons - to improve performance and/or catch real bugs. This 
> change, in practice, makes performance worse, and it doesn't catch real 
> bugs. It's pure pedantry.

I disagree. It's very much like the strict aliasing and the signed integer
overflow. Like these, the   <pointer> + <integer>   scenario with <pointer>
being NULL is an undefined-behaviour scenario that compiler writers will
be eager to exploit for optimization. And like in those other two cases,
our only choice is to be ISO C compliant, otherwise we risk "shocking"
optimizations.

Bruno