On 18/11/2023 09:44, Alejandro Colomar wrote: > Hi Jonny, > > On Fri, Nov 17, 2023 at 09:46:47PM +0000, Jonny Grant wrote: >>> Regarding other string-copying functions, NULL is not inherent to them, >>> so I'm not sure if they should have explicit NULL checks. Why would >>> these functions receive a null pointer? The main possibility is that >>> the programmer forgot to check some malloc(3) call, which should receive >>> a different treatment from a failed copy, normally. >> >> Perhaps it's just my point of view. In safety critical software I always do my best to ensure no code calls an API with the null pointer constant - when it's expecting a valid pointer. Given that the null pointer constant is defined in the C standard, even if APIs have undefined behaviour if they require a pointer but are passed a NULL. So the converse is I make APIs check for NULL (if they require a valid pointer) and reject with an error. Covers all bases (there can be corrupt data files occurring that we can't anticipate), so issues can be logged, and no core dump. I'd rather display a "USB device error 51" message on a UI than suffer a core dump which turns off a piece of safety critical equipment or sends it into a restart death loop. >> >> I recall you mentioned [[gnu::nonnull]] aka __attribute__((nonnull)) which is an optimizer hint the API will always be called with a valid pointer. There is also returns_nonnull. >> >> The difficulty is the optimizer will remove any NULL pointer constant checks within those APIs (if there were any). The side effect is a useful compiler warning, if the compiler figures out someone is passing NULL. >> >> So in a safety critical system we must wrap all such APIs, to put back in the null pointer constant checks. > > There's Clang's qualifier _Nonnull, which is not a hint to the > optimizer. It is an attempt to have null correctness similar to how we > have const correctness. It still has little support, even from Clang > itself. It has some important problem: it applies to the pointer, not > to the pointee, but pointer qualifiers are discarded easily. A better > design would make it a pointee qualifier. Hopefully, this will some day > be there to end all NULL discussions. Until then, yeah, NULL is a > dangerous part of the language. > > Cheers, > Alex > I saw Christopher Bazley was talking about this. As I understand it, _Nonnull is milder than attribute nonnull. _Nonnull probably helps with static analysis, but doesn't optimize out any code checking if(ptr == NULL) return -1; Saw this, did you get traction with your proposal? https://discourse.llvm.org/t/iso-c3x-proposal-nonnull-qualifier/59269?page=2 You're right NULL is a dangerous part of the language, there is part of the C spec that does state functions which don't document supporting arguments that are NULL, are undefined behaviour. It's implementation defined, and most don't check for it, which is fine, it's their choice. NULL is pretty easy to check for in a wrapper, simpler than catching use-after-free pointers at runtime, like valgrind or address sanitizer does. Paul Eggert drew my attention to this in C23: 7.1.4 Use of library functions "If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after default argument promotion) not expected by a function with a variable number of arguments, the behavior is undefined." Kind regards Jonny
