Reply to post: Re: If you want to do Low-Latency properly ...

Re: If you want to do Low-Latency properly ...

In-band signalling is a problem with C, not just with null-terminated¹ strings but with formatted I/O, another common source of vulnerabilities.

Of course as with most problems in computing, this was a trade-off. It arguably makes sense for the language's original use case, system programming on a machine with rather limited resources.

In C++ there's rarely any good reason to use C strings, except string literals to initialize C++ strings and other objects, and transient use of the value returned by the c_str method and similar when calling C functions. Of course much C++ code is just a mishmash of poor C++ and poor C compiled as C++, because many of the people who write C++ can't be bothered to learn the language. (In part that's the fault of the language; it's too damn big.)

In C, non-trivial programs should refactor string handling into higher-level abstractions that employ appropriate safeguards and memoize intermediate results. Inline sequences of strcat() and the like aren't just dangerous; they're a sign that the programmer couldn't be bothered to abstract and refactor properly. The same can be said of the use of "safer" string functions like strncpy (which has broken semantics) and the Annex K string functions (strcpy_s, etc, or nonstandard predecessors like strlcpy). As Richard Heathfield used to point out, a well-behaved program should know whether the result will fit in the target before attempting the operation, so that it can handle the error case correctly.

But from what I've seen (and I've seen a lot of C), very few C programmers have the discipline to do that.

¹An unfortunate aspect of the C standard (ISO-IEC 9899) is the overloaded use of the term "null", which can refer to a null pointer (a special value, not necessarily all-bits-zero, for a pointer type which indicates it does not refer to any object); a null pointer constant (an integer type with value 0, or the same cast to void*, when used in a pointer context); and the char object with all-bits-zero. For the last the committee would have done better to use "nul", the ASCII name for that code point.