5 ms·

> C doesn't try to save you from making mistakes. It has very few opinions about your code and happily assumes that you know exactly what you're doing. Freedom

by 9d 1y ago

> C doesn't try to save you from making mistakes. It has very few opinions about your code and happily assumes that you know exactly what you're doing. Freedom with responsibility. I love C because it doesn't make my life very inconvenient to protect me from stubbing my toe in it. I hate C when I stub my toe in it.

OCASMv2 1y ago
No, it just makes it inconvenient to try to protect yourself from stubbing your toe in it.
- codr7 1y ago
  C doesn't make anything inconvenient, that's its major appeal. Some things are convenient by design, yes, but it's not trying to prevent you from doing anything. That's a feature.
  - OCASMv2 1y ago
    > C doesn't make anything inconvenient Other than writing memory safe code, as history has shown.
    - codr7 1y ago
      Difficult, not inconvenient. Because it allows things that are difficult, like writing your own memory allocators. If you don't like working at that difficulty level, then C programming isn't for you. And that's fine.
      - OCASMv2 1y ago
        It doesn't allow me to write my own memory allocator, it forces me to. This line of argumentation reminds me of this: Advertise and promote a shortcoming or a fault as a virtue. For example, ultra-cheap single-use film cameras are advertised as "No Focusing Required." The truth is, no focusing is possible, because those cameras have cheap plastic fixed-focus lenses that won't move and can't be focused. What is a serious shortcoming for a camera — the inability to properly focus on the subject — is sold as a convenience: "You don't have to bother with focusing." https://orangepapers.eth.limo/orange-propaganda.html#make_virtue https://orangepapers.eth.limo/orange-propaganda.html#make_vi...
        codr7 1y ago
        No it doesn't, malloc() and free() is the default.
neonsunset 1y ago
Usually stubbing your toe does not take your whole leg.
0xEF 1y ago
I've heard it put another way that I enjoyed: "C assumes you know what you're doing, which is only a problem if you don't know what you're doing."
- tialaramex 1y ago
  Having spent many, many years paid to write C, and with no wish to write any more now than I learned Rust, I would suggest a rewording: "C assumes you know what you're doing, which is only a problem because you don't know what you're doing." Periodically, especially in r/cpp I run into people who are apparently faultless and so don't make the mistakes that make these languages dangerous, weirdly none of these people seem to have written any software I can inspect to see for myself what that looks like, and furthermore the universe I live in doesn't seem to have any of the resulting software. I choose to interpret this mystery as: People are idiots and liars, but of course there could be other interpretations.
  - psunavy03 1y ago
    > Periodically, especially in r/cpp I run into people who are apparently faultless and so don't make the mistakes that make these languages dangerous, weirdly none of these people seem to have written any software I can inspect to see for myself what that looks like, and furthermore the universe I live in doesn't seem to have any of the resulting software. So basically Jeff Sutherland ever since he started talking about AI. "My AI agents have formed a Scrum team that's 30 times faster than any human developer!" Great, Jeff. Working in which company's production codebase?
    - codr7 1y ago
      Yeah, well, as stated: software written by humans will have bugs. The real danger with Rust is the cult like delusion that's not the case for them.
      - tialaramex 1y ago
        To be sure, my Rust has bugs in it, but none of them come close to the spooky nonsense that could happen in my C and yet the performance is excellent. Probably more than once a day Rust's compiler rejects code that an analogous C compiler would wave through - and maybe it'd survive testing too, at least for a while.
codr7 1y ago
Oh, very much likewise, but there's always two sides to a coin.
oconnor663 1y ago
> It has very few opinions about your code I understand where this is coming from, but I think this is less true than it used to be, and (for that reason) it often devolves into arguments about whether the C standard is the actual source of truth for what you're "really" allowed to do in C. For example, the standard says I must never: - cast a `struct Foo*` into a `struct Bar*` and access the Foo through it (in practice we teach this as the "strict aliasing" rules, and that's how all(?) compilers implement it, but that's not what §6.5 paragraph 7 of the standard says!) - allow a signed integer to overflow - pass a NULL pointer to memcpy, even if the length is zero - read an unitialized object, even if I "don't care" what value I get - read and write a value from different threads without locking or atomics, even if I know exactly what instructions those reads and writes compile into and the ISA manual says it's 100% fine to do that All of these are ways that (modern, standard) C doesn't really "do what the programmer said". A lot of big real-world projects build with flags like -fno-strict-aliasing, so that they can get away with doing these things even though the standard says they shouldn't. But then, are they really writing C or "C with custom extensions"? When we compare C to other languages, whose extensions are we talking about?
- ryao 1y ago
  cast a `struct Foo*` into a `struct Bar*` and access the Foo through it (in practice we teach this as the "strict aliasing" rules, and that's how all(?) compilers implement it, but that's not what §6.5 paragraph 7 of the standard says!) Use the union type. Abusing it for aliasing violates the standard too, but GCC and Clang implement an extension that permits this. Alternatively, just allocate a char array and cast it as you please. Strict aliasing does not apply to char arrays if I recall. allow a signed integer to overflow Is this still true? I thought that the reason for this is because C left the implementation to define how signed arithmetic worked, meaning you could not assume two’s complement, but the most recent C standard was supposed to mandate two’s complement. pass a NULL pointer to memcpy, even if the length is zero There is a reason for this. memcpy is allowed to start reading early as a performance optimization, before it does a branch that checks if reading is only. I do wonder what happens if you only want to copy 1 byte and that byte has invalid memory right next to it. Presumably, this optimization would read more than a byte. read an unitialized object, even if I "don't care" what value I get You are probably doing something wrong if you do this. It is not even good as an entropy source. read and write a value from different threads without locking or atomics, even if I know exactly what instructions those reads and writes compile into and the ISA manual says it's 100% fine to do that Earlier C standards likely did not say anything about this because they did not support multithreading, but outside of possibly reading/writing to hardware registers, you do not want to do this because of races. Even if you think you know better, you almost certainly do not.

by 9d 1y ago

OCASMv2 1y ago

No, it just makes it inconvenient to try to protect yourself from stubbing your toe in it.

codr7 1y ago
C doesn't make anything inconvenient, that's its major appeal. Some things are convenient by design, yes, but it's not trying to prevent you from doing anything. That's a feature.
- OCASMv2 1y ago
  > C doesn't make anything inconvenient Other than writing memory safe code, as history has shown.
  - codr7 1y ago
    Difficult, not inconvenient. Because it allows things that are difficult, like writing your own memory allocators. If you don't like working at that difficulty level, then C programming isn't for you. And that's fine.
    - OCASMv2 1y ago
      It doesn't allow me to write my own memory allocator, it forces me to. This line of argumentation reminds me of this: Advertise and promote a shortcoming or a fault as a virtue. For example, ultra-cheap single-use film cameras are advertised as "No Focusing Required." The truth is, no focusing is possible, because those cameras have cheap plastic fixed-focus lenses that won't move and can't be focused. What is a serious shortcoming for a camera — the inability to properly focus on the subject — is sold as a convenience: "You don't have to bother with focusing." https://orangepapers.eth.limo/orange-propaganda.html#make_virtue https://orangepapers.eth.limo/orange-propaganda.html#make_vi...
      - codr7 1y ago
        No it doesn't, malloc() and free() is the default.

neonsunset 1y ago

Usually stubbing your toe does not take your whole leg.

0xEF 1y ago

I've heard it put another way that I enjoyed: "C assumes you know what you're doing, which is only a problem if you don't know what you're doing."

tialaramex 1y ago
Having spent many, many years paid to write C, and with no wish to write any more now than I learned Rust, I would suggest a rewording: "C assumes you know what you're doing, which is only a problem because you don't know what you're doing." Periodically, especially in r/cpp I run into people who are apparently faultless and so don't make the mistakes that make these languages dangerous, weirdly none of these people seem to have written any software I can inspect to see for myself what that looks like, and furthermore the universe I live in doesn't seem to have any of the resulting software. I choose to interpret this mystery as: People are idiots and liars, but of course there could be other interpretations.
- psunavy03 1y ago
  > Periodically, especially in r/cpp I run into people who are apparently faultless and so don't make the mistakes that make these languages dangerous, weirdly none of these people seem to have written any software I can inspect to see for myself what that looks like, and furthermore the universe I live in doesn't seem to have any of the resulting software. So basically Jeff Sutherland ever since he started talking about AI. "My AI agents have formed a Scrum team that's 30 times faster than any human developer!" Great, Jeff. Working in which company's production codebase?
  - codr7 1y ago
    Yeah, well, as stated: software written by humans will have bugs. The real danger with Rust is the cult like delusion that's not the case for them.
    - tialaramex 1y ago
      To be sure, my Rust has bugs in it, but none of them come close to the spooky nonsense that could happen in my C and yet the performance is excellent. Probably more than once a day Rust's compiler rejects code that an analogous C compiler would wave through - and maybe it'd survive testing too, at least for a while.

codr7 1y ago

Oh, very much likewise, but there's always two sides to a coin.

oconnor663 1y ago

> It has very few opinions about your code I understand where this is coming from, but I think this is less true than it used to be, and (for that reason) it often devolves into arguments about whether the C standard is the actual source of truth for what you're "really" allowed to do in C. For example, the standard says I must never: - cast a `struct Foo*` into a `struct Bar*` and access the Foo through it (in practice we teach this as the "strict aliasing" rules, and that's how all(?) compilers implement it, but that's not what §6.5 paragraph 7 of the standard says!) - allow a signed integer to overflow - pass a NULL pointer to memcpy, even if the length is zero - read an unitialized object, even if I "don't care" what value I get - read and write a value from different threads without locking or atomics, even if I know exactly what instructions those reads and writes compile into and the ISA manual says it's 100% fine to do that All of these are ways that (modern, standard) C doesn't really "do what the programmer said". A lot of big real-world projects build with flags like -fno-strict-aliasing, so that they can get away with doing these things even though the standard says they shouldn't. But then, are they really writing C or "C with custom extensions"? When we compare C to other languages, whose extensions are we talking about?

ryao 1y ago
cast a `struct Foo*` into a `struct Bar*` and access the Foo through it (in practice we teach this as the "strict aliasing" rules, and that's how all(?) compilers implement it, but that's not what §6.5 paragraph 7 of the standard says!) Use the union type. Abusing it for aliasing violates the standard too, but GCC and Clang implement an extension that permits this. Alternatively, just allocate a char array and cast it as you please. Strict aliasing does not apply to char arrays if I recall. allow a signed integer to overflow Is this still true? I thought that the reason for this is because C left the implementation to define how signed arithmetic worked, meaning you could not assume two’s complement, but the most recent C standard was supposed to mandate two’s complement. pass a NULL pointer to memcpy, even if the length is zero There is a reason for this. memcpy is allowed to start reading early as a performance optimization, before it does a branch that checks if reading is only. I do wonder what happens if you only want to copy 1 byte and that byte has invalid memory right next to it. Presumably, this optimization would read more than a byte. read an unitialized object, even if I "don't care" what value I get You are probably doing something wrong if you do this. It is not even good as an entropy source. read and write a value from different threads without locking or atomics, even if I know exactly what instructions those reads and writes compile into and the ISA manual says it's 100% fine to do that Earlier C standards likely did not say anything about this because they did not support multithreading, but outside of possibly reading/writing to hardware registers, you do not want to do this because of races. Even if you think you know better, you almost certainly do not.