On 24.02.2020 05:03, Taylor R Campbell wrote: >> Date: Sun, 23 Feb 2020 22:51:08 +0100 >> From: Kamil Rytarowski <n54%gmx.com@localhost> >> >> On 23.02.2020 20:08, Taylor R Campbell wrote: >> Date: Sun, 23 Feb 2020 22:51:08 +0100 >> From: Kamil Rytarowski <n54%gmx.com@localhost> >> >> On 23.02.2020 20:08, Taylor R Campbell wrote: >>>> Date: Sat, 22 Feb 2020 17:25:42 +0100 >>>> From: Kamil Rytarowski <n54%gmx.com@localhost> >>>> >>>> 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. > Forbidding NULL pointer arithmetic is not just for C purists trolls. It is now in C++ mainstream and already in C2x draft. The newer C standard will most likely (already accepted by the committee) adopt nullptr on par with nullptr from C++. In C++ we can "#define NULL nullptr" and possibly the same will be possible in C. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2394.pdf This will change all arithmetic code operating on NULL into syntax error. > 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'. > memcpy(3) and other string functions are different. It is undefined if we just run it with memcpy(rand(), rand(), 0) and the first two arguments point to invalid memory. memcpy(0, 0, x) have another issue with overlapping memory that makes it undefined. In theory memcpy(x,y,z) where x or y are 0 is valid, whenever we map 0x0 in the address space, but that is so rare that GCC defines these arguments as nonnull.
Attachment:
signature.asc
Description: OpenPGP digital signature