[jandrewrogers]

The use of goto is unambiguously correct and elegant in some contexts. Unwavering avoidance of goto can lead to unnecessarily ugly, convoluted code that is difficult to maintain. It usually isn't common but it has valid uses.

While use of functions like `strcpy` are less advisable, there are contexts in which they are guaranteed to be correct unless other strong (e.g. language-level) invariants are broken, in which case you have much bigger problems. In these somewhat infrequent cases, there is a valid argument that notionally safer alternatives may be slightly less efficient for no benefit.

[sirwhinesalot]

strcpy and friends don't really have any benefits beyond just being there. The "safer" versions are still unsafe in many cases, while being less performant and more annoying to use.

Writing a strbuffer type and associated functions isn't particularly hard and the resulting interface is nicer to use, safer, and more efficient.

[bvrmn]

I argue strview (non-owning) is almost always what is needed. Most of string operations are searching and slicing.

[sirwhinesalot]

You also need a strview. Not really relevant for avoiding strcpy and strcat though.

[xedrac]

> The use of goto is unambiguously correct and elegant in some contexts.

For C, absolutely. For C++, it's likely a footgun.

[jandrewrogers]

It has fewer use cases in C++ but it still has use cases where the alternatives are worse.

[xedrac]

What is a C++ use case where RAII doesn't solve the problem better? I imagine one exists, but I've never encountered it in 20 years. Conversely, I've seen it used inappropriately for cleanup many times (which would be fine in C).