And that again, is the point. That stuff should be built-in and almost non-negotiable. It should be a lot more work to do the unsafe thing (see: Rust).
They are negotiable in Rust too. Just use the unsafe keyword everywhere. If you want to use a language where they are non-negotiable, use JavaScript.
Secure string functions are built into C these days. The older error prone ones are as well. You can ban the older functions from code bases, but it is hard to justify outright bans for all of them. If you audit string function usage in a non-trivial codebase, you likely will find instances where the old, error prone, string functions are used in safe ways and leaving them alone makes sense. This is particularly the case when constant length strings are used with constant length buffers. Here is an example where the old string functions are just as safe as the secure string functions:
I found it when I audited the string function usage in OpenZFS with the goal of removing all uses of the older string functions. While I replaced every instance old string function where the secure string functions mitigated even the slightest risk, I could not bring myself to remove these, since there was nothing wrong with them. After my patches, a few string functions were then banned from the codebase with a build system hack put in place to break the build process if someone tried to reintroduce the banned functions.
Secure string handling functions like strlcpy() and strlcat() do have bounds checks. Not everyone uses them sadly.
And that again, is the point. That stuff should be built-in and almost non-negotiable. It should be a lot more work to do the unsafe thing (see: Rust).
They are negotiable in Rust too. Just use the unsafe keyword everywhere. If you want to use a language where they are non-negotiable, use JavaScript.
Secure string functions are built into C these days. The older error prone ones are as well. You can ban the older functions from code bases, but it is hard to justify outright bans for all of them. If you audit string function usage in a non-trivial codebase, you likely will find instances where the old, error prone, string functions are used in safe ways and leaving them alone makes sense. This is particularly the case when constant length strings are used with constant length buffers. Here is an example where the old string functions are just as safe as the secure string functions:
https://github.com/openzfs/zfs/blob/master/etc/systemd/syste...
I found it when I audited the string function usage in OpenZFS with the goal of removing all uses of the older string functions. While I replaced every instance old string function where the secure string functions mitigated even the slightest risk, I could not bring myself to remove these, since there was nothing wrong with them. After my patches, a few string functions were then banned from the codebase with a build system hack put in place to break the build process if someone tried to reintroduce the banned functions.