2 - no enforcement that a null terminator actually exists in the string
3 - C brags about performance and is probably the slowest language to compute string length
4 - manipulating strings requires very carefull handling of buffers, usually forcing everyone to use the heap as easier way out
If you are going to mention Assembly as possibility, check ClearPath where there is no Assembly, NEWP has full control over the hardware stack.
Obviously, since many other languages that do so are implemented in C.
Those are not practical? Billions of dollars have been wasted on issues stemming from this...
Or is the insinuation that we are hand-wavy about it, and you doubt the existence and scale of the problem? It's a well researched, well established problem, known for almost half a century.
https://en.wikipedia.org/wiki/C_standard_library#Buffer_over...
https://security.web.cern.ch/security/recommendations/en/cod...
http://www.informit.com/articles/article.aspx?p=430402&seqNu...
https://randomascii.wordpress.com/2013/04/03/stop-using-strn...
https://courses.cs.washington.edu/courses/cse341/04wi/lectur... (null termination)
https://www.geeksforgeeks.org/why-strcpy-and-strncpy-are-not...
https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Ov...:
And let's not even get into format string issues...
I have a feeling that of all axes of performace C cares the most about memory overhead. Then the obvious idea is to have it at exatly one byte per "simple" string, and you get to pick the class of programs that can't get away with that default string type:
• One-byte terminator: complicated text-handling application with a lot of (longer than a couple of pointers on average) string slices.
• One-byte length: anything that needs strings longer than 255 chars.
And then of these two solutions you pick the obviously more general one. What could possibly go wrong?
Character arrays with open length, bound checked.
Naturally it requires better compiler support than C authors were willing to implement.
Which is still the case with many things in Go, a language of close origin to C (though this time not about strings).
I guess security is not relevant as infrastructure work.
> I guess security is not relevant as infrastructure work.
...
And our data through some JS monstrosity.
So?
Strange argument. Javascript is widespread, COBOL was widespread, Windows is widespread, X86 is widespread. Widespread doesn't mean good. UNIX was a disaster, and the whole family of UNIX-like OS spent decades just for mitigate its errors and faults.
And nowadays C code is considered legacy, with C#, Rust and constrained C++ as the road to the future.
All the listed weaknesses also have benefits. For instance it is easy to get a substring without need to copy.
But yes, many bugs in C software originate from spring buffer overflows.
That substring won't remain valid without copying it.
Unless it's not modified? And unless, when modified, that shouldn't be its new value?
C Strings (nul-terminated) are the right approach for static storage of small static strings (like strings literals in the source code) since they have low overhead, and "substrings" aren't second-class citizens.
For dynamically allocated strings that won't be modified after creation, the right approach is using a large memory chunk that is shared between many such strings, plus two indices for offset / length (or just offset if it's text that can be terminated with a sentinel).
Having a short string of about 10 characters allocated as a dynamic object in its own allocation is wasteful. Slow to allocate and has about 2x to 3x overhead. This approach isn't good for applications that store a large amount of data.
> O(N) is not the same as O(1).
Don't call strlen() in situations where the strings are large and you need to know the length ahead of time, and running time is paramount. Instead, store the length.
I can tell you that in one of my programs, the difference between garbage collected strings and optimized ones (actually, strings converted into unique integer handles immediately) for one of my projects (SAT solver in Java), handling a few million variables, was something like a second until completion vs a couple of minutes before the garbage collector finally dies due to lack of oxygen, losing all data computed up to that point.
To make substring in some other languages, you need to store pointer to beginning of the substring and length of substring.
To make substring in C, you need to store pointer to beginning of the substring and put '\0' into original string.
Plus a pointer to the beginning, plus a reference counter as the user expects it to manage lifetime. In C this is the user's job. Where they know the life time is guaranteed they can optimize.