Re: do { quit; } else { }

On 09/04/2025 15:00, David Brown wrote:

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

Not really me.

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

So who's right, you or Tim? Since you are saying contrary things.

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

According to that, then the 'Point' and 'vector' types in my original two-file example are not compatible, since they have different struct tags, plus they have different member names. But above you say they are 'entirely compatible'.
Maybe it's /you/ who needs brush up on the Standard! I merely said they are compatible enough to my program to work, since at the machine level, this is merely two consecutive f32 types.
BTW1 that paragraph doesn't say anything what 'pack()' setting is in force; that /has/ to be the same if otherwise different amounts of padding exist.
BTW2 that doesn't really say anything about how to share named non-linkage entities across translation units.

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.

You're welcome to post the same example in a more mainstream language. However most still seem to based around independent compilation. Many still require two parts to each shared resource: a definition, and a separate interface, with some mechanism needed to keep them in sync.
My scheme only needs a definition for resources forming part of the same program. It also works for ALL named entities, not just those with 'linkage'.

  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.

If there was a 1:1 correspondence between a .c file and its .h, that would be great, but that rarely happens. In the LIBJPEG project for example, there are 76 .c files, and 12 .h files (but at least they are in the same folder).
There are still risks: suppose a project uses include files in multiple locations made known to the compiler. It will follow an implementation-defined algorithm to search multiple paths for an include file. But if one accidentally gets deleted or renamed, if may pick up up an identically named file elsewhere. They may be similar enough to allow compilation to proceed, but now it is buggy.

  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.

The point is that C's scheme is 'ad hoc' with myriad (רבבה?) points of failure. You like to deny that. (Apparently if a compiler follows the same consistent set of rules, then it cannot be 'ad hoc'. But you can say this about any computer program; they are only following orders!)