[jasode]

>It's only your opinion that the code is wrong based on the interpretation of the program's identifiers through an English dictionary.

No, that isn't quite right. I'm the one who authored that code example so even if I used opaque non-English struct tag names such as "struct s1{}" and "struct s2{}" instead of "struct meter{}" and "struct inch{}", my brain intended for s1 and s2 to not be mixed and matched carelessly. Poster mikulas_florek suggested wrapping plain ints with a struct and my example shows that that workaround doesn't accomplish what he says it does.

>It is well-defined ISO C.

Yes, and I wanted to emphasize that truism by showing a live example of a successful compilation in ideone.com!

I thought the thread was about higher-level semantics rather than the set of trivially true sequences of text input that the compiler accepts.

[kazinator]

It's trivial to come up with successful compiles of C code that does invoke undefined behavior.

Successful C compilation rarely means that only higher-level semantics not encoded into type system is now violated.

The battles in C are already being lost in the trenches of lower-level semantics.

If worrying about these higher level things and getting them right were the only problem in C development, C development would be in fantastic shape.

In safe languages which don't have type systems that can express pounds versus inches in inviolable ways, that sort of thing is rarely any sort of obstacle to real work; it's a fluff concern.

If I have to program in something which has no way of enforcing pounds being added to inches, and that is the only significant drawback of that language, I'm laughing.

[jasode]

>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.

[kazinator]

You can in fact just declare struct meters in a header file, and don't publish the full declaration. The client C can still get at the data, but only in underhanded ways, like guessing at what the structure looks like and locally completing the declaration. Without that being done, the pointer cannot be dereferenced; that is a constraint violation for which ISO C requires a diagnostic. C support for making opaque data type API's is reasonably decent. You can make a type for meters that doesn't interoperate with anything but other instances of meters, other than through some serialization hole (you provide a necessary function to scan meters from a string or print to a string, and using that, someone can convert meters to just a double and add it to similiarly deserialized kilograms).