[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/kern
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.
> 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
I think the problem is that if you have the series of statements,
element_t *e = &s->element;
if (s == NULL)
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.
dyoung%pobox.com@localhost Urbana, IL (217) 721-9981
Main Index |
Thread Index |