If I proposed a new strxyzcpy function that only null-terminated the string when the length was not a prime number and that wiped your hard drive if the destination string, before the copy, contained the sequence 'xyz' in ascii I would be very afraid someone in the C committee would think it would be a nice idea to add it.

Does the length take locale into consideration?

FFS I had some code for a microcontroller break because locale.

Don’t forget than if it’s invoked at the 38th second of a minute, the behavior is undefined.

Oh, are those 0-indexed seconds or 1-indexed?

0-indexed if running on a Unix-like OS, 1-indexed otherwise.

Does Linux count as Unix-like? What if it’s NixOS?

Implementation defined.

A great tweet, and often useful. But I don't think it applies well here.

There is a long history of "this time, the strcpy replacement will be safe" followed by cve after cve after cve. At some point I feel that the response really should be to give up on trying to make c-style strings safe.

The problem is the function signatures of all the improved string functions are broken. You can never write a safe string function that takes two char pointers.

You really want

  int str_try_copy(str_buffer *dest, str_slice *src)

You are more than welcome to give up on it. Personally I feel that you can never make code that handles C strings secure. That said, people will still be using them decades from now, and it is possible to give them safer APIs. Discounting everything as "oh it can never be perfect therefore we might as well throw away any efforts to make it better" is not helpful.