5 ms·

I do not question the usefulness of C, I use it in my daily work. What I am saying is that most C developers that use the language day-in-day-out know quite wel

by Dinux 9y ago

I do not question the usefulness of C, I use it in my daily work. What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing, and don't need yet another non-standard way of writing the code. Safety is a good point, but the initiative doesn't even mention the word, and there is no reason to assume the C-for-All extension targets safety at all

s73v3r_ 9y ago
"What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing" I'm going to strongly disagree with that statement.
- saagarjha 9y ago
  I might have agreed with you if this was C++. C is a small enough language that most programmers can understand most of it.
  - s73v3r_ 9y ago
    Toyota was full of programmers that apparently "understood what they were doing."
    - saagarjha 9y ago
      Bad practices can carry over to any language. They’re clearly incompetent at using C, but that doesn’t mean that they won’t be incompetent in another language.
    - ori_b 9y ago
      Fair point, but changing the language won't change the amount of global state. and the associated complexity, nor will it make subsystem supervision work correctly. Changing the language will not prevent unbounded recursion or the associated stack overflows and subsystem failures. Changing the language will not fix mis-analysis of task switching overhead. And changing the language will not fix manufacturing issues with the PCBs. As far as I'm aware, one of the very few toolchains that even try to improve on this over C are Ada/SPARK.
      - vvanders 9y ago
        > but changing the language won't change the amount of global state Global mutable state is marked as Unsafe in Rust. > nor will it make subsystem supervision work correctly Erlang is built specifically around this concept. Perfect is the enemy of good here, throwing out a whole language due to one case doesn't help anyone.
        ori_b 9y ago
        > Global mutable state is marked as Unsafe in Rust. It's also the simplest way to avoid dynamic allocation and the associated OOM issues. So, short of doing static analysis to bound heap usage at compile time, that makes things worse. And Toyota already got the static analysis wrong for their stack usage. At least globals will fail to compile if they won't fit.
    - cbdumas 9y ago
      Are you referring to the "unintended acceleration" scandal from ~10 years ago? If so the NHTSA investigated[0] that and found no flaws in electronics. The problem was essentially people pushing the gas when they thought they were on the brakes. Pedal "misapplication" I think it's called in the report. [0] https://www.transportation.gov/briefing-room/us-department-transportation-releases-results-nhtsa-nasa-study-unintended-acceleration https://www.transportation.gov/briefing-room/us-department-t...
      - seandougall 9y ago
        In that investigation they seemed to place the blame more on sticky pedals and floor mats, not operator error. That wasn't the final word, though. I believe this is what the GP was referring to: > When NASA software engineers evaluated parts of Toyota’s source code during their NHTSA contracted review in 2010, they checked 35 of the MISRA-C rules against the parts of the Toyota source to which they had access and found 7,134 violations. Barr checked the source code against MISRA’s 2004 edition and found 81,514 violations. ... > Their descriptions of the incredible complexity of Toyota’s software also explain why NHTSA has reacted the way it has and why NASA never found a flaw it could connect to a Toyota’s engine going to a wide open throttle, ignoring the driver’s commands to stop and not set a diagnostic trouble code. For one, Barr testified, the NASA engineers were time limited, and did not have access to all of the source code. They relied on Toyota’s representations – and in some cases, Toyota misled NASA. http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code http://www.safetyresearch.net/blog/articles/toyota-unintende...
      - abainbridge 9y ago
        > The problem was essentially people pushing the gas when they thought they were on the brakes Oh dear no. Certainly not. Read https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... My favourite part from is, "Watchdog kicked by a hardware timer service routine". A watchdog timer is a piece of hardware that decrements a counter every microsecond or similar. The control system's main loop, running on the CPU, "kicks" the watchdog by setting the counter to a value like 1000 each iteration. The result is that if the CPU fails to execute the main loop often enough, the watchdog will "fire". This a) tells you that you have a bug and b) typically reboots the system so it has a chance to recover. Toyota used a timer service routine to kick the watchdog. This defeats the purpose of the watchdog. The control software can happily get stuck or crash and the watchdog will not notice. The fact that an engineer added this "feature" tells you that the watchdog was firing in development. That should have been addressed by fixing the buggy software, not by disabling the test. The fact that the disabled watchdog made it into the production release is unforgivable.
pjmlp 9y ago
Even ANSI/ISO C working group acknowledges that “thrust the programmer” doesn’t quite work.
- gmueckl 9y ago
  This is because trusting the programmer is fundamentally wrong, no matter the programming language. In any good development process the actual coding is the least amount of work - for a reason.
  - pjmlp 9y ago
    This was the statement I was referring to. <quote> Spirit of C: a. Trust the programmer. b. Do not prevent the programmer from doing what needs to be done. c. Keep the language small and simple. d. Provide only one way to do an operation. e. Make it fast, even if it is not guaranteed to be portable. The C programming language serves a variety of markets including safety-critical systems and secure systems. While advantageous for system level programming, facets (a) and (b) can be problematic for safety and security. Consequently, the C11 revision added a new facet: => f. Make support for safety and security demonstrable. </quote> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf
    - gmueckl 9y ago
      Okay, this makes me rethink my previous statement. There are two kinds of trust here: A low level programming language should not impose restrictions on the code that prevent the programmer from doing what needs to be done, even if it looks wrong. This is how I read the 'Spirit of C" that you quoted. And certain applications would be impossible to write without it. But you need a development process to make sure that your system does exactly the right thing. So the quote should read "trust the process" rather than "trust the programmer".

by Dinux 9y ago

s73v3r_ 9y ago

"What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing" I'm going to strongly disagree with that statement.

saagarjha 9y ago
I might have agreed with you if this was C++. C is a small enough language that most programmers can understand most of it.
- s73v3r_ 9y ago
  Toyota was full of programmers that apparently "understood what they were doing."
  - saagarjha 9y ago
    Bad practices can carry over to any language. They’re clearly incompetent at using C, but that doesn’t mean that they won’t be incompetent in another language.
  - ori_b 9y ago
    Fair point, but changing the language won't change the amount of global state. and the associated complexity, nor will it make subsystem supervision work correctly. Changing the language will not prevent unbounded recursion or the associated stack overflows and subsystem failures. Changing the language will not fix mis-analysis of task switching overhead. And changing the language will not fix manufacturing issues with the PCBs. As far as I'm aware, one of the very few toolchains that even try to improve on this over C are Ada/SPARK.
    - vvanders 9y ago
      > but changing the language won't change the amount of global state Global mutable state is marked as Unsafe in Rust. > nor will it make subsystem supervision work correctly Erlang is built specifically around this concept. Perfect is the enemy of good here, throwing out a whole language due to one case doesn't help anyone.
      - ori_b 9y ago
        > Global mutable state is marked as Unsafe in Rust. It's also the simplest way to avoid dynamic allocation and the associated OOM issues. So, short of doing static analysis to bound heap usage at compile time, that makes things worse. And Toyota already got the static analysis wrong for their stack usage. At least globals will fail to compile if they won't fit.
  - cbdumas 9y ago
    Are you referring to the "unintended acceleration" scandal from ~10 years ago? If so the NHTSA investigated[0] that and found no flaws in electronics. The problem was essentially people pushing the gas when they thought they were on the brakes. Pedal "misapplication" I think it's called in the report. [0] https://www.transportation.gov/briefing-room/us-department-transportation-releases-results-nhtsa-nasa-study-unintended-acceleration https://www.transportation.gov/briefing-room/us-department-t...
    - seandougall 9y ago
      In that investigation they seemed to place the blame more on sticky pedals and floor mats, not operator error. That wasn't the final word, though. I believe this is what the GP was referring to: > When NASA software engineers evaluated parts of Toyota’s source code during their NHTSA contracted review in 2010, they checked 35 of the MISRA-C rules against the parts of the Toyota source to which they had access and found 7,134 violations. Barr checked the source code against MISRA’s 2004 edition and found 81,514 violations. ... > Their descriptions of the incredible complexity of Toyota’s software also explain why NHTSA has reacted the way it has and why NASA never found a flaw it could connect to a Toyota’s engine going to a wide open throttle, ignoring the driver’s commands to stop and not set a diagnostic trouble code. For one, Barr testified, the NASA engineers were time limited, and did not have access to all of the source code. They relied on Toyota’s representations – and in some cases, Toyota misled NASA. http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code http://www.safetyresearch.net/blog/articles/toyota-unintende...
    - abainbridge 9y ago
      > The problem was essentially people pushing the gas when they thought they were on the brakes Oh dear no. Certainly not. Read https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... My favourite part from is, "Watchdog kicked by a hardware timer service routine". A watchdog timer is a piece of hardware that decrements a counter every microsecond or similar. The control system's main loop, running on the CPU, "kicks" the watchdog by setting the counter to a value like 1000 each iteration. The result is that if the CPU fails to execute the main loop often enough, the watchdog will "fire". This a) tells you that you have a bug and b) typically reboots the system so it has a chance to recover. Toyota used a timer service routine to kick the watchdog. This defeats the purpose of the watchdog. The control software can happily get stuck or crash and the watchdog will not notice. The fact that an engineer added this "feature" tells you that the watchdog was firing in development. That should have been addressed by fixing the buggy software, not by disabling the test. The fact that the disabled watchdog made it into the production release is unforgivable.

pjmlp 9y ago

Even ANSI/ISO C working group acknowledges that “thrust the programmer” doesn’t quite work.

gmueckl 9y ago
This is because trusting the programmer is fundamentally wrong, no matter the programming language. In any good development process the actual coding is the least amount of work - for a reason.
- pjmlp 9y ago
  This was the statement I was referring to. <quote> Spirit of C: a. Trust the programmer. b. Do not prevent the programmer from doing what needs to be done. c. Keep the language small and simple. d. Provide only one way to do an operation. e. Make it fast, even if it is not guaranteed to be portable. The C programming language serves a variety of markets including safety-critical systems and secure systems. While advantageous for system level programming, facets (a) and (b) can be problematic for safety and security. Consequently, the C11 revision added a new facet: => f. Make support for safety and security demonstrable. </quote> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf
  - gmueckl 9y ago
    Okay, this makes me rethink my previous statement. There are two kinds of trust here: A low level programming language should not impose restrictions on the code that prevent the programmer from doing what needs to be done, even if it looks wrong. This is how I read the 'Spirit of C" that you quoted. And certain applications would be impossible to write without it. But you need a development process to make sure that your system does exactly the right thing. So the quote should read "trust the process" rather than "trust the programmer".