Re: do { quit; } else { }

On 09/04/2025 15:13, bart wrote:

On 09/04/2025 13:36, David Brown wrote:

On 09/04/2025 12:51, bart wrote:

I'll have to think about this before replying to any other points.

>
Marvellous - I'd appreciate you putting more thought into this, and less knee-jerk reactions and exaggerations.  Please also read the relevant parts of the standards before replying - at the very least, section 6.2.7p1 and section 6.2.2.  Once you have read these and tried to understand them, it will be a lot easier to clear up any remaining issues.

 I'm not going to wade through reams of Standard minutiae, sorry.

Again, no one is suggesting that you read the entire C standard.  After all, that would clearly be an absurd idea for someone who spends such a lot of his time arguing about the C language and who even claims to have made a C compiler.
I have given you clear references to two small parts of the standard. It really is not a lot of effort.

 Are T and U compatible types are not? The answer must be unequivocal without needing to be a 'standards-head'.

I have told you several times, for different variations of that "T" and "U" mean.
Since you don't believe my explanations, and won't read the standards, I'm not sure how much more help I can be.

This has been said in this thread:
  BC: The types involved are somewhat different, but are compatible enough
     for it to work. [In that the member types, offsets and overall size,
     since pass-by-value is used, correspond]
 DB: The two types are entirely compatible.
 BC: Are they?
 TR: No, they are not.
 You say they're compatible, Tim Rentsch says they're not; who's right?
 

You have moved the goalposts around so often that it is hard to keep track.  But Tim is correct - the names, when given, have to match as well as the types of the fields (but a typedef alias giving a different name to the same type is fine).

 The original point I'd been making was that, in C, there is no dedicated mechansism for sharing user-defined named entities like types, across modules.

There /is/ a dedicated mechanism - described in 6.2.7p1.
There is also a common way to handle this - using shared header files - that is almost universally adopted in C programming.
It is not as strict as in some other languages, and is open to abuse - but you pretty much have to go out of your way to mix things up.  Follow normal C programming methods, and you will have no more risk of mistakes here than in languages with more formal inter-unit interfacing.

I notice you ignored the example in my language, many posts back, which makes it impossible to make such a mistake.

Yes, I ignore your examples in your language - they have no bearing or relevance to anyone except you.  We all know there are other ways for a language to implement inter-unit sharing of information.  We all know that some of these can reduce the risk of certain errors.  We all know that you have to follow a simple rule in order to negate that risk in C - put shared types in shared headers.  No language negates all risks of errors - whatever language you use, you follow practices that balance the risk of errors with the convenience or flexibility that you want in the code.