On 07.11.2019 13:17, Valery Ushakov wrote: > On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote: > >> I have checked received the following patch and received a feedback from >> a LLVM developer. >> >> On 07.11.2019 05:47, 'Dmitry Vyukov' via syzkaller-netbsd-bugs wrote: >>> I've consulted with some people and _presumably_ (to the degree one >>> can be sure about bitter corner cases of C/C++ :)) this is a correct >>> fix (and formally correct warnings from ubsan). >>> As 188.8.131.52/4 says, only &*p and &p[i] syntactic forms are defined as >>> special case of not being a dereference, but rather effectively an >>> address calculation. But &p->m is not. Thus it is interpreted as a >>> dereference that produces an lvalue and then taking address of that >>> lvalue. At the point of dereference we have UB. Your fix avoids the >>> dereference. > > The context is lost in the thread, but the original change was about > &dlp->d_magic as far as I can figure out. If the claim is that that's > UB b/c dlp is improperly aligned, then why the half of the rest of the > file is not UB as it uses the same "dlp" pointer to access other > members of the disklabel. >
We were already addressing various reports for disklabel related code in the kernel and userland. In userland we as far as I recall just copy the struct into an aligned promptly pointer. There might be more problems, but we address them as they pop up. > As a side note - the C99 standard contains "derefer" exactly once, in > a footnote. Since we have ended up in the darkest corners of > legalistic exegesis, please, can we avoid using the word that is, > technically speaking, meaningless as far as this discussion is > concerned? > > -uwe > Unary * oprator. C++ specified term "dereferenceable" in the context of the unary * operator.
Description: OpenPGP digital signature