4 ms·

In my opinion the three original sins of C are: nullptr, null-terminated strings, and implicit conversions. Abolish those three concepts and C is a significant

In my opinion the three original sins of C are: nullptr, null-terminated strings, and implicit conversions. Abolish those three concepts and C is a significantly improved language!

pjmlp 4y ago
no bounds checkings, enums are hardly better than #define, pointer decay....
- jstimpfle 4y ago
  > pointer decay This is an issue? Works fine for me.
  - pjmlp 4y ago
    It does wonders for security researchers jobs, because the idea of typing &arr[0] instead was asking too much.
    - jstimpfle 4y ago
      Why _can_ you write &arr[0] in the first place? There is at least some logic behind it (which probably breaks down with multidimensional arrays, a feature that probably wasn't there from the start). In C, I suspect that at least in the beginning, there were never arrays on the type and expression level - only pointers. What security problems are exactly caused by pointer decay? A similar thing also exists with calls through function pointers, and I do not think you can find many programmers who are willing to write (*foo)(x, y, z) when using function pointers (at least not when there are many, like when using e.g. OpenGL). Or worse, (&foo)(x, y, z) with normal functions.
      - pjmlp 4y ago
        The usual stuff that array lengths on function declarations are only guidelines, given that they are plain pointers, and when one calculates the array length not taking that into account, somewhere out there there is an happy hacker.
jstimpfle 4y ago
> nullptr, null-terminated strings Any system that lacks them will have to hack them back in at some point, in one form or another. Option<types> are not an option for C, and sentinels like NULL work just fine.
- forrestthewoods 4y ago
  > Any system that lacks them will have to hack them back in at some point, in one form or another. Only because the C FFI is the lingua franca of operating systems. > Option<types> are not an option for C Disagree. C could absolutely support SumTypes / TaggedUnions. > sentinels like NULL work just fine. Spans/Slices are objectively superior. Null terminated strings aren't the biggest source of pain in the universe, but they're problematic. I'm not arguing that C _should_ add these things today. I'm saying that C made bad choices 50 years ago and we're paying the price to this day. This isn't pointing fingers. It'd be upsetting if the industry hadn't made progress and didn't learn better ways to do things!
  - jstimpfle 4y ago
    > Only because the C FFI is the lingua franca of operating systems. No, because they are genuinely useful. How should you best implement Option<type> for pointers? Right, using NULL as a sentinel. And representing sum types explicitly in the type system (instead of ad-hoc using sentinels) would add a huge amount of complexity. I still like the simplicity of zero-terminated strings. They are self-contained strings that can be passed around as a simple char-pointer. No other format can give you this simplicity. They are still an acceptable default for string literals. And whenever you have a non-trivial usecase, just use the best string representation for that. You don't need to use zero-terminated strings everywhere. Use a macro like this for a dumb length-delineated string struct MyString { const char *ptr; int length; }; #define S(stringlit) (struct MyString) { "" slit, sizeof slit - 1 }; Done!

In my opinion the three original sins of C are: nullptr, null-terminated strings, and implicit conversions. Abolish those three concepts and C is a significantly improved language!

pjmlp 4y ago

no bounds checkings, enums are hardly better than #define, pointer decay....

jstimpfle 4y ago
> pointer decay This is an issue? Works fine for me.
- pjmlp 4y ago
  It does wonders for security researchers jobs, because the idea of typing &arr[0] instead was asking too much.
  - jstimpfle 4y ago
    Why _can_ you write &arr[0] in the first place? There is at least some logic behind it (which probably breaks down with multidimensional arrays, a feature that probably wasn't there from the start). In C, I suspect that at least in the beginning, there were never arrays on the type and expression level - only pointers. What security problems are exactly caused by pointer decay? A similar thing also exists with calls through function pointers, and I do not think you can find many programmers who are willing to write (*foo)(x, y, z) when using function pointers (at least not when there are many, like when using e.g. OpenGL). Or worse, (&foo)(x, y, z) with normal functions.
    - pjmlp 4y ago
      The usual stuff that array lengths on function declarations are only guidelines, given that they are plain pointers, and when one calculates the array length not taking that into account, somewhere out there there is an happy hacker.

jstimpfle 4y ago

> nullptr, null-terminated strings Any system that lacks them will have to hack them back in at some point, in one form or another. Option<types> are not an option for C, and sentinels like NULL work just fine.

forrestthewoods 4y ago
> Any system that lacks them will have to hack them back in at some point, in one form or another. Only because the C FFI is the lingua franca of operating systems. > Option<types> are not an option for C Disagree. C could absolutely support SumTypes / TaggedUnions. > sentinels like NULL work just fine. Spans/Slices are objectively superior. Null terminated strings aren't the biggest source of pain in the universe, but they're problematic. I'm not arguing that C _should_ add these things today. I'm saying that C made bad choices 50 years ago and we're paying the price to this day. This isn't pointing fingers. It'd be upsetting if the industry hadn't made progress and didn't learn better ways to do things!
- jstimpfle 4y ago
  > Only because the C FFI is the lingua franca of operating systems. No, because they are genuinely useful. How should you best implement Option<type> for pointers? Right, using NULL as a sentinel. And representing sum types explicitly in the type system (instead of ad-hoc using sentinels) would add a huge amount of complexity. I still like the simplicity of zero-terminated strings. They are self-contained strings that can be passed around as a simple char-pointer. No other format can give you this simplicity. They are still an acceptable default for string literals. And whenever you have a non-trivial usecase, just use the best string representation for that. You don't need to use zero-terminated strings everywhere. Use a macro like this for a dumb length-delineated string struct MyString { const char *ptr; int length; }; #define S(stringlit) (struct MyString) { "" slit, sizeof slit - 1 }; Done!