4 ms·

No, it's not a complex language. Come on.

gypsyharlot 5y ago
Then why do the seasoned veteran C programmers keep introducing memory security vulnerabilities all the time? Some of the projects considered by many to be idiomatic C keep introducing terrible bugs... Sqlite, Redis, etc.
- pca006132 5y ago
  I don't think bugs are introduced due to the language being very complex, but the problem/solution being complex. To prevent (some of) these, you may need a more complex solution, like what Rust provides.
adwn 5y ago
Would you like to address the arguments in my post instead of going "Na-ah, you're wrong, I'm right"?
- darthrupert 5y ago
  I get your point, but I'm queamish on how far you stretch the definition of the word "complex". C has these problems because it's simple, i.e. it provides a rather thin abstraction layer over machine language. Rust's corresponding layer is much thicker due to its memory requirements and historical origins.
  - adwn 5y ago
    > it provides a rather thin abstraction layer over machine language. No, it doesn't, and it hasn't for quite some time – not since C compilers started exploiting undefined behavior for optimization opportunities. It used to be that if you wrote a + b where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. Even worse, code which was working correctly for 20 years might start exhibiting subtle bugs from one day to the next, just because you've upgraded your compiler from version 9.4.2 to 9.4.3. Undefined behavior is one major reason why writing correct C code is complex and difficult in practice.
    - jcelerier 5y ago
      > where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. it's the exact opposite - if you want your compiler to just emit an ADD no matter which platform you are on, then it cannot be the language that defines the semantics of "+" in the corner cases (thus UB). If you define it as overflow on 2's complement, then on a DSP with saturating arithmetic your compiler will have to emit additional instructions to detect if you are saturating and wrap instead.
SAI_Peregrinus 5y ago
The C11 standard is 701 pages. The "Language" section (ignoring the Environmet, definitions of terms, standard library, and appendices) is 145 pages. And it's hillariously underspecified even without ignoring all that; there's tons of implementation-defined (documented independently by each compiler), unspecified (compilers must pick a behavior from a list and document which choice they made), and undefined (not required to be documented by any compiler) behavior.
- phendrenad2 5y ago
  Before anyone takes this post at it's word, I encourage you to go look at the C11 standard. It's called "ISO/IEC 9899:201x" and those of you who have seen an ISO standard before will already know where I'm going with this! > 145 pages Yes, and (within that 145) they take a whole page to define the word "scope". Not even in the context of C!! Just the general language-agnostic term "Scope". That's hardly meaningful...
  - SAI_Peregrinus 5y ago
    Which page within the 145 (chapter 6)? The section on scopes of identifiers (6.2.1, pgs 35-36) is entirely in the context of the C language.
    - phendrenad2 5y ago
      Exactly that one. I'll let people read it to come to their own determination as to how "entirely in the context of the C language" it is.

Then why do the seasoned veteran C programmers keep introducing memory security vulnerabilities all the time? Some of the projects considered by many to be idiomatic C keep introducing terrible bugs... Sqlite, Redis, etc.

pca006132 5y ago
I don't think bugs are introduced due to the language being very complex, but the problem/solution being complex. To prevent (some of) these, you may need a more complex solution, like what Rust provides.

adwn 5y ago

Would you like to address the arguments in my post instead of going "Na-ah, you're wrong, I'm right"?

darthrupert 5y ago
I get your point, but I'm queamish on how far you stretch the definition of the word "complex". C has these problems because it's simple, i.e. it provides a rather thin abstraction layer over machine language. Rust's corresponding layer is much thicker due to its memory requirements and historical origins.
- adwn 5y ago
  > it provides a rather thin abstraction layer over machine language. No, it doesn't, and it hasn't for quite some time – not since C compilers started exploiting undefined behavior for optimization opportunities. It used to be that if you wrote a + b where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. Even worse, code which was working correctly for 20 years might start exhibiting subtle bugs from one day to the next, just because you've upgraded your compiler from version 9.4.2 to 9.4.3. Undefined behavior is one major reason why writing correct C code is complex and difficult in practice.
  - jcelerier 5y ago
    > where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. it's the exact opposite - if you want your compiler to just emit an ADD no matter which platform you are on, then it cannot be the language that defines the semantics of "+" in the corner cases (thus UB). If you define it as overflow on 2's complement, then on a DSP with saturating arithmetic your compiler will have to emit additional instructions to detect if you are saturating and wrap instead.

SAI_Peregrinus 5y ago

The C11 standard is 701 pages. The "Language" section (ignoring the Environmet, definitions of terms, standard library, and appendices) is 145 pages. And it's hillariously underspecified even without ignoring all that; there's tons of implementation-defined (documented independently by each compiler), unspecified (compilers must pick a behavior from a list and document which choice they made), and undefined (not required to be documented by any compiler) behavior.

phendrenad2 5y ago
Before anyone takes this post at it's word, I encourage you to go look at the C11 standard. It's called "ISO/IEC 9899:201x" and those of you who have seen an ISO standard before will already know where I'm going with this! > 145 pages Yes, and (within that 145) they take a whole page to define the word "scope". Not even in the context of C!! Just the general language-agnostic term "Scope". That's hardly meaningful...
- SAI_Peregrinus 5y ago
  Which page within the 145 (chapter 6)? The section on scopes of identifiers (6.2.1, pgs 35-36) is entirely in the context of the C language.
  - phendrenad2 5y ago
    Exactly that one. I'll let people read it to come to their own determination as to how "entirely in the context of the C language" it is.