Re: CVS commit: src/sys/kern

[David Young <dyoung%pobox.com@localhost>]

On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
> > On 07.11.2019 14:25, Valery Ushakov wrote:
> > > If the sanitizer does complain about other uses, there is little point
> > > in fixing one instance and not the others.
> > 
> > We already agreed with Christos that this is appeasing of GCC. If you
> > want to scan the whole kernel (or whole C) file for more occurrences of
> > violations - please go for it.
> 
> No. The commit needs to be reverted, and then
> 
>  a) either the root cause for the unaligned address be fixed or
>  b) some other means be found to make the sanitizer shut up
> 
> As uwe said: papering over a tiny detail that *never* hits in the real
> world but potentialy hiding a real issue is not the way to go.
> 
> Martin
> 
> P.S.: Independend of this I would still like an official C standard
> clarification; in my reading a simple address calculation is not
> accessing an object through a pointer (which would be the undefined
> behaviour). If the C standard is not clear on this, it needs to be
> improved.

I think the problem is that if you have the series of statements,

        element_t *e = &s->element;

        if (s == NULL)
                return;

then the comparison with NULL implies that in this scope, s could
be NULL.  NULL does not necessarily have any "arithmetic" relationship
to any other pointer---by that rationale, you probably cannot assign
any alignment to it---so there is no sensible value that you can
give to e.

There is probably an argument to be made that in a
segmented/tagged/capability architecture that has run C programs
(8086; Burroughs Large Systems) or may run them in the future (CHERI),
&(NULL)->element cannot sensibly be computed.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981