3 ms·

But a lot of APIs take a void* and size_t pair, where one is a buffer and another is a length. It is pretty unreasonable for ptr=NULL, len=0 to be UB, if the co

But a lot of APIs take a void* and size_t pair, where one is a buffer and another is a length. It is pretty unreasonable for ptr=NULL, len=0 to be UB, if the code will not follow the pointer when len == 0. TFA says that is the case for some libc functions. I agree that this is unreasonable. Eg. memcpy shouldn't care if pointers it should not follow are invalid; a copy of length 0 ought to be spec'd as a no-op.

skissane 4y ago
> It is pretty unreasonable for ptr=NULL, len=0 to be UB, if the code will not follow the pointer when len == 0. Many of these cases were due to backward compatibility - different pre-existing implementations did different things, everybody wanted to claim conformance to the standard but nobody wanted to change their existing behaviour to do so (potentially breaking their existing application base), so the political compromise was to make them UB. Thankfully, the ISO C standards committee, in recent years, seems less afraid to make breaking changes than they used to be. And many of these UB cases were to placate implementations that are now long-dead-sometimes you’ll find that despite being UB, most or all major contemporary implementations do the same thing, which increases the odds that a future release of the standard might standardise those behaviours. But this is what happens when a programming language gets to be 50 years old.