2 ms·

Creators Admit Unix/C Are a Hoax

12 points by nickpsecurity 10y ago

nickpsecurity 10y ago
This came to mind when another thread had people trying to explain why C could have undefined behavior with so many combinations of simple statements that don't cause problems in other languages. The semantics are so bad we can get a Poe's Law effect with an essay like above. Probably someone out there that would think it was true lol.
- kazinator 10y ago
  I will try to give a very short answer to that one. A given situation is undefined in C because out of some 42 assembly languages, the analogous situation doesn't work on at least one of them, or it works in all of them, but not in the same way. E.g. a shift by more than the width of he operand type might work "modulo" in one assembly language (<< 33 means << 1) because the low 5 bits of the shift are used. In another it might produce a zero result (all bit are shifted into the bucket). Oh dear, how do we document the requirement for C? Why, we allow both possibilities. No wait, that would be too good. Let's allow both possibilities, and demons to fly out of the programmer's or user's nose.
  - nickpsecurity 10y ago
    I was thinking it could be simplified with two possibilities: a reference behavior that's sane and predictable; a non-portable, native, whatever behavior with warning that not using it means anything goes & resulting code must be expected for correctness. That can just be called Undefined. So, you get CorrectBehaviorNumberWhatever OR UndefinedIfNativeBehavior. Then, like with KCC compiler, you can have the compiler parse the program and fail by default w/ error message on any undefined behavior. These can be suppressed per module or file basis. This is what safer, system languages do. Use sane, defined stuff for almost your entire program. Hide anything hardware specific or inherently unsafe in modules labeled as such where you know it's undefined and must be thoroughly checked.

2 ms·

Creators Admit Unix/C Are a Hoax

12 points by nickpsecurity 10y ago

nickpsecurity 10y ago
This came to mind when another thread had people trying to explain why C could have undefined behavior with so many combinations of simple statements that don't cause problems in other languages. The semantics are so bad we can get a Poe's Law effect with an essay like above. Probably someone out there that would think it was true lol.
- kazinator 10y ago
  I will try to give a very short answer to that one. A given situation is undefined in C because out of some 42 assembly languages, the analogous situation doesn't work on at least one of them, or it works in all of them, but not in the same way. E.g. a shift by more than the width of he operand type might work "modulo" in one assembly language (<< 33 means << 1) because the low 5 bits of the shift are used. In another it might produce a zero result (all bit are shifted into the bucket). Oh dear, how do we document the requirement for C? Why, we allow both possibilities. No wait, that would be too good. Let's allow both possibilities, and demons to fly out of the programmer's or user's nose.
  - nickpsecurity 10y ago
    I was thinking it could be simplified with two possibilities: a reference behavior that's sane and predictable; a non-portable, native, whatever behavior with warning that not using it means anything goes & resulting code must be expected for correctness. That can just be called Undefined. So, you get CorrectBehaviorNumberWhatever OR UndefinedIfNativeBehavior. Then, like with KCC compiler, you can have the compiler parse the program and fail by default w/ error message on any undefined behavior. These can be suppressed per module or file basis. This is what safer, system languages do. Use sane, defined stuff for almost your entire program. Hide anything hardware specific or inherently unsafe in modules labeled as such where you know it's undefined and must be thoroughly checked.