Re: NULL pointer arithmetic issues

[Aaron Ballman <aaron%aaronballman.com@localhost>]

On Mon, Mar 9, 2020 at 12:36 PM Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>
> On Mon, Mar 09, 2020 at 09:50:50AM -0400, Aaron Ballman wrote:
> > On Sun, Mar 8, 2020 at 2:30 PM Taylor R Campbell
> > > I ask because in principle a conformant implementation could compile
> > > the NetBSD kernel into a useless blob that does nothing -- we rely on
> > > all sorts of behaviour relative to a real physical machine that is not
> > > defined by the letter of the standard, like inline asm, or converting
> > > integers from the VM system's virtual address allocator into pointers
> > > to objects.  But such an implementation would not be useful.
> >
> > Whether an optimizer elects to use this form of UB to make
> > optimization decisions is a matter of QoI. My personal feeling is that
> > I don't trust this sort of optimization -- it takes code the
> > programmer wrote and makes it behave in a fundamentally different
> > manner. I'm in support of UBSan diagnosing these constructs because it
> > is UB and an optimizer is definitely allowed to optimize based on it
> > but I wouldn't be in support of an optimizer that aggressively
> > optimizes on this.
>
> I consider it as something even worse. Just like the case of passing
> NULL pointers to memcpy and friends with zero as size, this
> interpretation / restriction in the standard is actively harmful to some
> code for the sake of potential optimisation opportunities in other code.
> It seems to be a poor choice at that. I.e. it requires adding
> conditional branches for something that behaves sanely everywhere but
> may the DS9k.

+1 -- I'm personally not a fan of allowing these kinds of
optimizations. I refer to the entire class of similar operations as
"exploiting undefined behavior" for this reason.

~~Aaron

>
> Joerg