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 dyo...@pobox.com Urbana, IL (217) 721-9981