How interesting. GCC does indeed remove that branch.<p><a href="https://godbolt.org/z/aPcr1bfPe" rel="nofollow">https://godbolt.org/z/aPcr1bfPe</a>
I just skimmed through the proposed wording in [N3322]. It looks like it silently fixes a defect too, NULL == NULL was also undefined up until C23. Hilarious.<p>[N3322] <a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf</a>
I feel like I've misunderstood something here... shouldn't memcpy(anything, anything, 0) just do nothing, because you're copying 0 bytes?
> However, the most vocal opposition came from a static analysis perspective: Making null pointers well-defined for zero length means that static analyzers can no longer unconditionally report NULL being passed to functions like memcpy—they also need to take the length into account now.<p>How does this make any sense? We don't want to remove a low hanging footgun because static analyzers can no longer detect it?
Isn't it more sensible to just check that the params that are about to be sent to memcpy be reasonable?<p>That is why I tend to wrap my system calls with my own internal function (which can be inlined in certain PLs), where I can standardize such tests. Otherwise, the resulting code that performs the checks and does the requisite error handling is bloated.<p>Note that I am also loath to #DEFINE such code because C is already rife with them and my perspective is that the less of them the better.<p>At the end of the day, quick and dirty fixes will prove the adage "short cuts make long delays", and OpenBSD's approach is the only really viable long-term solution, where you just have to rewrite your code if it has ill-advised constructs.<p>For designing libraries such as C's stdlib, I don't believe in 'undefined behavior', clearly define your semantics and say, "If you pass a NULL to memcpy, this is what will happen." Same for providing a (n == 0), or should (src == dst).<p>And if, for some strange reason, fixing the semantics breaks calling code, then I can't imagine that their code wasn't f_cked in the first place.
> because NULL + 0 is undefined behavior in C.<p>Why? It's 2024. Make it not be? Sure, some older stuff already written might no longer compile and need to be updated. Put it behind a "newer" standard flag/version or whatever.<p>Or is it that it can't be caught at compile time and only run time... hmm...