SoylentNews is people
SoylentNews
Ladies and gentlemen, the C programming language. It’s a classic. It is blindingly, quicksilver fast, because it’s about as close to the bone of the machine as you can get. It is time-tested and ubiquitous. And it is terrifyingly dangerous.
The author's biggest issue with the C language seems to be security holes:
If you write code in C, you have to be careful not to introduce subtle bugs that can turn into massive security holes — and as anyone who ever wrote software knows, you cannot be perfectly careful all of the time.
The author claims that the Rust language is a modern answer to these issues and should replace C (and C++). It does look that Rust can run C code, so it looks like an interesting proposition. What do Soylent's coders think about this?
(Score: 4, Insightful) by krishnoid on Saturday May 09 2015, @12:41AM
There's basically two ways to store string on the machine level: magic character terminated (null-terminated C strings) or you store the length of the string somewhere.
There are multiple problems with the second approach. First, you waste a lot of space allocating memory for a large integer if all of your strings are short in length (and remember that back when C was invented, this kind of thing mattered as memory was expensive and limited).
Sure -- is this as much of an issue nowadays? I can see this would add, say, 3 bytes (minus one NULL + 4 bytes) to every string, or possibly less, if memory accesses are 4-byte-aligned anyway and the strings aren't packed together tightly.
Second, there's a maximum limit on the length of your strings, or else you overflow your length integer and potentially run into bugs and security vulnerabilities (in the interest of fairness, this kind of overflow is less dangerous than a buffer overflow).
That would be 4GB for a 4-byte unsigned int, which is long for a string. Point taken in your fairness in comparing the overflow severity and that overwrites can still happen.
Third, there isn't any advantage over using the null-terminated approach and just storing the length of the string in a integer variable yourself, which is in fact what many C programs do (but not all! C doesn't force you to store the length if you do not need it).
If you're doing that for all your strings, shouldn't a language (or standard library) supporting that behind the scenes be better and faster, turning at least some O(n) operations into O(1) for non-multiplicative increase in memory use? For your second point, what programs manipulate and copy strings without referring to their length frequently? I could make the argument that for the majority of application modalities in use nowadays, a string is closer to a (not CPU-wise) 'native type' and should have a strlen()-like operation be O(1).
(Score: 2) by darkfeline on Monday May 11 2015, @12:22AM
>Sure -- is this as much of an issue nowadays? I can see this would add, say, 3 bytes (minus one NULL + 4 bytes) to every string, or possibly less, if memory accesses are 4-byte-aligned anyway and the strings aren't packed together tightly.
No, but backward compatibility IS an issue. C is what it is because back then memory was an issue.
>That would be 4GB for a 4-byte unsigned int, which is long for a string. Point taken in your fairness in comparing the overflow severity and that overwrites can still happen.
Again, memory used to be an issue. If you need good string support there are many alternatives: C++, Golang, Common Lisp, Java for example.
>If you're doing that for all your strings, shouldn't a language (or standard library) supporting that behind the scenes be better and faster, turning at least some O(n) operations into O(1) for non-multiplicative increase in memory use? For your second point, what programs manipulate and copy strings without referring to their length frequently? I could make the argument that for the majority of application modalities in use nowadays, a string is closer to a (not CPU-wise) 'native type' and should have a strlen()-like operation be O(1).
But you don't necessarily need that for all of your strings, do you? If I know that the strings/blobs I am working on will be less than a given size and I am running an algorithm that linearly passes over the string, I can just allocate the memory in one go and not have to worry about the length ever.
C was designed with the UNIX philosophy in full force: do not dictate policy! If the end user (the developer) does not want or need strings with length, do not force it on them. Note that C can perfectly well use length-strings instead of null-strings, in that case they are just length-defined binary buffers. (Chars are just bytes, strings are just char arrays with a NUL at the end.) The UNIX Dev Team Thinks Of Everything.
Join the SDF Public Access UNIX System today!