re: NULL pointer arithmetic issues
> 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'. well said. i 100% agree. these extreme edge-cases of UB that have a very clear definition don't seem to he helpful in finding any real class of bugs and only seem to be good at cluttering up working code. .mrg.
Re: NULL pointer arithmetic issues
> Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski > > On 23.02.2020 20:08, Taylor R Campbell wrote: > Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski > > On 23.02.2020 20:08, Taylor R Campbell wrote: > >> Date: Sat, 22 Feb 2020 17:25:42 +0100 > >> From: Kamil Rytarowski > >> > >> 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'.
Re: NULL pointer arithmetic issues
On 23.02.2020 20:08, Taylor R Campbell wrote:
>> Date: Sat, 22 Feb 2020 17:25:42 +0100
>> From: Kamil Rytarowski
>>
>> When running the ATF tests under MKLIBCSANITIZER [1], there are many
>> NULL pointer arithmetic issues .
>>
>> http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt
>>
>> These issues are in macros like:
>> - IN_ADDRHASH_READER_FOREACH()
>> - IN_ADDRLIST_WRITER_INSERT_TAIL()
>> - IFADDR_READER_FOREACH()
>> - etc
>>
>> These macros wrap internally pserialize-safe linked lists.
>>
>> 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;
or
char *p = NULL;
if (p[0] == NULL) {}
signature.asc
Description: OpenPGP digital signature
Re: NULL pointer arithmetic issues
> Date: Sat, 22 Feb 2020 17:25:42 +0100 > From: Kamil Rytarowski > > When running the ATF tests under MKLIBCSANITIZER [1], there are many > NULL pointer arithmetic issues . > > http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt > > These issues are in macros like: > - IN_ADDRHASH_READER_FOREACH() > - IN_ADDRLIST_WRITER_INSERT_TAIL() > - IFADDR_READER_FOREACH() > - etc > > These macros wrap internally pserialize-safe linked lists. > > 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
