> Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski <n...@gmx.com> > > On 23.02.2020 20:08, Taylor R Campbell wrote: > Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski <n...@gmx.com> > > On 23.02.2020 20:08, Taylor R Campbell wrote: > >> Date: Sat, 22 Feb 2020 17:25:42 +0100 > >> From: Kamil Rytarowski <n...@gmx.com> > >> > >> What's the proper approach to address this issue? > > > > What do these reports mean? > > > > UBSan: Undefined Behavior in > > /usr/src/sys/rump/net/lib/libnet/../../../../netinet6/in6.c:2351:2, pointer > > expression with base 0 overflowed to 0 > > We added 0 to a NULL pointer. > > They can be triggered by code like: > > char *p = NULL; > p += 0;
It seems to me the proper approach is to teach the tool to accept this, and to avoid cluttering the tree with churn to work around the tool's deficiency, unless there's actually a serious compelling argument -- beyond a language-lawyering troll -- that (char *)NULL + 0 is meaningfully undefined. We already assume, for example, that memset(...,0,...) is the same as initialization to null pointers where the object in question is a pointer or has pointers as subobjects. I think we should treat memcpy(NULL,NULL,0) similarly and tell the tool `no, on NetBSD that really is defined and we're not interested in hearing about theoretical nasal demons from armchair language lawyers'.