Re: do { quit; } else { }

On 10/04/2025 23:23, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 10/04/2025 12:28, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Someone, not anyone but the all-knowing Tim, said: "and those types
are not compatible, because the two struct tags are different."
>
Do you agree with that? Or is there something more to making two types
be incompatible?

I don't recall the exact discussion

>
It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
+0200". (About half way down there is some quoted code of mine.)
>
It concerned two struct types in different translations units, which
needed to be compatible for the test program to work corectly.
>
I said they were compatible enough. David said they were entirely
compatible. Tim said "No they are not". Three different opinions.

 Either David or Tim was right; I don't much care which.

No? BUT YOU CARE VERY MUCH THAT I AM WRONG!

You were wrong.

See?! Funny that isn't it; two people both make strong unequivocal statements that are at odds with each other, such that one is likely to be wrong, but you don't care about putting THEM right.
Yet I make a minor observation, and everyone comes down on me like a ton of bricks.

There is no such thing as "compatible enough"; two types
either are compatible or are not compatible.  I won't speculate on what
you might have meant by "compatible enough".

You must have seen the example, and based on my lifetime experience in low level coding, those types ARE compatible enough: one consists of two consecutive 32-bit floats, so does the other. What more is needed?
I don't buy the nonsense in the standard that the member names must match; what possible difference can that make?
I will admit it might not meet /those/ standards for compatibility, that's why I said it was compatible enough. That is, for all practical purposes.
And this was my original point: the C language can't force a sharing of a particular type; compatibility between the versions seen in different translations is on trust. This is the reason for member names having to be the same, to make it less likely that the structs match by chance, and to encourage people to share the same definition via a header.
This is why my example chose different tags and different names (and wrapped one set of member types in a typedef): it DELIBERATELY created two structs which were compatible at the machine level (ie. both being the tuple (f32, f32)), but likely intended for different purposes.
And that was to back up my point that C could not detect the usage of such a mix of types.
Do you understand now WHY I said 'compatible enough'?
Are you are utterly incapable of understanding anything outside of the 'the standard'?
 > Either David or Tim was right; I don't much care which.
This is now of most interest to me; somebody might be wrong on some detail of the C standard, but you don't care?!
I don't buy it. I don't know what's going on here but it stinks.