| >Successful C compilation rarely means _that only_ higher-level semantics not encoded into type system is now violated. I didn't make that claim that UB goes away with a successful compilation and therefore "only" the higher-level semantics are worth studying. Since nobody in this thread said that, I'm puzzled why you'd think I'd have such a naive position. >these higher level things and getting them right were _the only_ problem in C development, But I'm not arguing they are "the only" problem. Again, poster mikulas_florek suggested a code technique that claims to address a problem but does not work. That's the limited scope of my demo code. I don't know how theoretically fixing that tiny snippet got elevated to be the "savior to all C problems". I made no such grand claim. >, that sort of thing is rarely any sort of obstacle to real work; it's a fluff concern. Whether it is or isn't in relation to actual millions of lines of real-world code that may or may benefit from it is not relevant. Curl is an example of real working C Language software that may have zero code requiring type-checked units-of-measure. That's still not relevant to the previous poster mikulas_florek mis-educating C programmers. Btw, the units-of-measure is just one variation of the "type check" issue. Many times a programmer will have a function definition such as (customer_id x, action_code y). If the programmer accidentally reverses the 2 typedefs, the compiler won't catch that. Example: http://ideone.com/2dyT9n That type of human error happens all the time and I disagree that would be a "fluff concern". So, getting to hyper-focused on specific type failure examples such as units-of-measure instead of considering the more generalized higher-level errors not caught by C compiler is missing the point of what the thread is about. |