The point is not about « can not use them ».
If you deal with a small nail, you don’t go grab the sledgehammer you use your brain and pick the right tool for the job.
What I’m saying is that they don’t replace them but are an extra tool to use when you don’t need the extra capability.
Say you have a large global buffer you reuse to build various URL with parametes. It would be OK by me to strcpy() the initial first part of the url (« http://server.com/project/dothis » or « http://server.com/project/dothat ») as you know for sure there is enough room For this text.
Then in a loop You would use
strlcat() for adding your parameters for example esp. if there is unknown data length at compile time and check for proper behavior
But you could also check the available memory in the buffer before using
strcat() if you don’t want to mess up the buffer content (add part of a parameter and have a complex fall back error management to get to the previous content) and decide to send a well formed (even if incomplete) request and then repeat for the remaining data (sending well formed chunked requests maximizing buffer size for example if you are in a fixed size packet based radio).
Why would you use strlcpy() for the first one or use strlcat() for the other ones if you check room beforehand to keep a well formed URL in the buffer besides following corporate coding guidelines?
There is no risk, it’s a function call doing the right thing and not premature optimization in my view. It’s the normal hammer, not the sledgehammer.
It’s fine if you see differently or if you make the coding rules in your company and just want to not have to deal with deeper code review at all for engineering cost reason and are fine with the additional small performance/resource penalty - but don’t make abusive generalization and say the code will crash if you do this. It won’t if you have your brain on when you code.
My point - when coding for small microcontrollers especially - is know your tools and use the right one for the task at hand but follow corporate rules if there is such a norm where you develop. (I’ve seen thriving environments with both approaches- those with strict code reviews and more freedom in coding tend to attract and retain better programmers)
PS: and because you are a smart programmer who knows its functions, you do that yourself in your library...
or is it "do as I say, not as I do"