3 ms·

I'm a C programmer and i agree with this - C is fundamentally flawed from security viewpoint. However security isn't everything about the language. The reason w

I'm a C programmer and i agree with this - C is fundamentally flawed from security viewpoint. However security isn't everything about the language. The reason we don't switch to "C alternatives" is that they all have flaws and don't replace the flexibility and versatility of C/C++. E.g draconian type systems(Ada) or pedantic enforcement of memory safety(Rust). When programming in your language is painful, no one will switch to it, and C/C++ will continue to dominate and be the basis of most software stacks/operating systems/runtimes. An analogy is: why are you using a car which is unsafe,expensive, polluting and prone to road accidents, instead of safe, reliable, cheaper and environmentally friendly cargo tricycle?

userbinator 9y ago
An analogy is: why are you using a car which is unsafe,expensive, polluting and prone to road accidents, instead of safe, reliable, cheaper and environmentally friendly cargo tricycle? Or a motorcycle, which is even more unsafe --- but "hella fun", in the words of a friend. I'd rather drive, being in control, and take the risk than be forced to ride in a safe, boring, highly-regulated self-driving car.
- FrozenVoid 9y ago
  Thats would be assembler and demoscene.
- ClassyJacket 9y ago
  You aren't just putting yourself at risk by driving, you're putting other people at risk too.
- ido 9y ago
  this may apply to a motorcycle you ride for fun (hobby project?) but when I program for a living my top priority is to best/fastest solve the problem at hand, not to have fun.
xenadu02 9y ago
If I could wave a magic wand I'd have the C standards committee: 1. Add safe arrays to the next version of the standard. These arrays would work much like C arrays do, but taking a reference or passing to another function would pass an array_ref type rather than decaying to a pointer. Under the covers an array_ref would be a (size_t, address). Taking a reference to an element in the middle of an array would get the correct size of the reference. The default mode would be to bounds-check accesses to array_ref, aborting on failure. Since the array_ref knows its size it would be easy to check the index and return an error code if you prefer not to abort ("if (i >= sizeof some_array_param)"). 2. Make signed integer math trap on overflow and add wrapping variants (similar to Swift's &-prefixed versions of operators). For some projects this would be too disruptive but compilers would undoubtedly offer options to disable it. But the fact that this existed at all would immediately start pushing people to adopt it for the same reason people like to adopt -Weverything or -Wall. 2b. Add generic functions to check for potential overflow so we can have an officially blessed way to say "if x + y > INT_MAX" with no undefined behavior. This is so easy to accidentally get wrong without any obvious indication that you've introduced undefined behavior. 3. Some blessed reference counting library and/or types. If C had something to say about memory management other than "you're on your own" it would be a big boon to eliminating dangling pointers and use-after-free. I recognize there are many contexts where this isn't appropriate (e.g. embedded that statically allocates all memory at startup) but a lot of C code could adopt a stdlib-provided reference counting system if it existed. ARC has proven you can get everything except cycle detection without too much overhead. I'm sure people could quibble with the exact solutions I've proposed and there may be other things I've missed, but I'd really like to see the standard admit that C has a really nasty legacy and do something about it.

userbinator 9y ago

An analogy is: why are you using a car which is unsafe,expensive, polluting and prone to road accidents, instead of safe, reliable, cheaper and environmentally friendly cargo tricycle? Or a motorcycle, which is even more unsafe --- but "hella fun", in the words of a friend. I'd rather drive, being in control, and take the risk than be forced to ride in a safe, boring, highly-regulated self-driving car.

FrozenVoid 9y ago
Thats would be assembler and demoscene.
ClassyJacket 9y ago
You aren't just putting yourself at risk by driving, you're putting other people at risk too.
ido 9y ago
this may apply to a motorcycle you ride for fun (hobby project?) but when I program for a living my top priority is to best/fastest solve the problem at hand, not to have fun.

xenadu02 9y ago

If I could wave a magic wand I'd have the C standards committee: 1. Add safe arrays to the next version of the standard. These arrays would work much like C arrays do, but taking a reference or passing to another function would pass an array_ref type rather than decaying to a pointer. Under the covers an array_ref would be a (size_t, address). Taking a reference to an element in the middle of an array would get the correct size of the reference. The default mode would be to bounds-check accesses to array_ref, aborting on failure. Since the array_ref knows its size it would be easy to check the index and return an error code if you prefer not to abort ("if (i >= sizeof some_array_param)"). 2. Make signed integer math trap on overflow and add wrapping variants (similar to Swift's &-prefixed versions of operators). For some projects this would be too disruptive but compilers would undoubtedly offer options to disable it. But the fact that this existed at all would immediately start pushing people to adopt it for the same reason people like to adopt -Weverything or -Wall. 2b. Add generic functions to check for potential overflow so we can have an officially blessed way to say "if x + y > INT_MAX" with no undefined behavior. This is so easy to accidentally get wrong without any obvious indication that you've introduced undefined behavior. 3. Some blessed reference counting library and/or types. If C had something to say about memory management other than "you're on your own" it would be a big boon to eliminating dangling pointers and use-after-free. I recognize there are many contexts where this isn't appropriate (e.g. embedded that statically allocates all memory at startup) but a lot of C code could adopt a stdlib-provided reference counting system if it existed. ARC has proven you can get everything except cycle detection without too much overhead. I'm sure people could quibble with the exact solutions I've proposed and there may be other things I've missed, but I'd really like to see the standard admit that C has a really nasty legacy and do something about it.