Re: do { quit; } else { }

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

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

On 09/04/2025 10:42, David Brown wrote:

On 08/04/2025 18:28, bart wrote:

On 08/04/2025 15:50, David Brown wrote:

>

The two types are entirely compatible.

>
>
Are they?

>
Yes.
>

So why does gcc report an error here (the two types are from my example):
>
   typedef struct point {float a; float b;} Point;
>
   typedef float length;
   typedef struct _tag {length x, y;} vector;
>
   Point p;
   vector v;
>
   p=v;
>
c.c:14:5: error: incompatible types when assigning to type 'Point' {aka 'struct point'} from type
ector' {aka 'struct _tag'}
    14 |   p=v;
       |     ^
>

>
That is a different situation.  In the first case, the types were defined in different translation units - and are compatible.  In the second case, they are within the same translation unit, and are not compatible.

>
This doesn't make sense at all.
>
Turning it around, you're saying that if T an U are incompatible types within the same translation unit, they suddenly become compatible if split across two translation units?
>

 In the specific case of structs and unions matching the requirements in 6.2.7, yes.  /Please/ read that section of the standard before making any more posts about it.
 There are plenty of differences between compiling two C files independently, and pasting them directly together in one file and compiling that.  This is one of those differences.
 

>

In C, if you declare two structs in the same translation unit with the same field types and the same field names, they are still different types.  That is important for making new types - it is how you get strong typing in C (albeit with less user convenience than in some other languages).  It means that you can't mix up two types just because of coincidences in the fields.
>
This means that when you have a struct declaration in two translation units (locally in the C file, or via a header file - there is no distinction), they form two different types as they are separate declarations.  If C did not specify that these were compatible, it would be impossible (without UB) to use struct or union types across translation units.

>
So, yes, you are saying that. In short, if a programmer says that incompatible types T and U are the same (where the compiler can only see T in module A and U in module B), then the programmer must be trusted, even though they would be wrong.
>

 Yes.
 

Note that I, as the programmer, said this:
>
"The types involved are somewhat different, but are compatible enough for it to work."
>

 It's not quite like that - C says that although they are different types (since they are in different translation units), they are compatible in this situation.  Not "compatible enough to work", but /actually/ compatible in the specific C technical sense.  (Section 6.2.7 has "compatible type" in italics - it defines what is meant by that term in the C language.)
 

What you are saying is that even though I was actually telling the truth, I was wrong. But I would be right if I lied about it....
>

 No, you were not telling the truth - you were wildly mixing things.
 

We're either through the Looking-Glass at this point, or somewhere not in Kansas!
>
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.
Are T and U compatible types are not? The answer must be unequivocal without needing to be a 'standards-head'. 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?
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.
The user has to arrange for the compiler to see corresponding type declarations in each translation unit. This is error prone, and means that an RGBFLOAT struct can be used in place of a CIRCLE struct, and they will superficially work as each comprises three floats.
But it would be an error in the program logic, one that cannot be picked up by the compiler.
However you also state that RGBFLOAT and CIRCLE are compatible nonetheless. Even though, if you take the two modules are legally compiled before, and put refactor them into the same module, will now no longer compile.
You seem to be saying that if this was an actual mistake on the part of the programmer, it's still actually fine as as far as the compiler and language is concerned (so we're still in Wonderland!)
I notice you ignored the example in my language, many posts back, which makes it impossible to make such a mistake. That is how you fix such problems, not sending someone off to sweat through the 700 pages of C standard to prove some stupid point.
So I still say they approach in C is ad hoc. (There are ways to mitigate that, but many come down to wrapping or superimposing a higher level language layer on top.)