Isn't it more sensible to just check that the params that are about to be sent to memcpy be reasonable? That is why I tend to wrap my system calls with my own

Isn't it more sensible to just check that the params that are about to be sent to memcpy be reasonable? 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. 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. 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. 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). 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.