Re: do { quit; } else { }

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.

 

You are still wrong.

 Never mind. I've just spotted this at the end. In that case, and given what you said above where you arguing that Black is White, discussion is futile.
 

I believe there is still hope.  But it does require you to read and think.