Re: do { quit; } else { }

bart <bc@freeuk.com> writes:

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 because you said something that doesn't make sense.

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.

Correct.

Yet I make a minor observation, and everyone comes down on me like a
ton of bricks.

You make a minor nonsensical observation, and continue to double down on
it when we point out that it doesn't make sense.

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?

An understanding of what "compatible types" means.  You claim to have
read that part of the standard, but you still seem to be insisting that
type compatibility has something to do with type representation.  It
doesn't.  Two compatible types will have the same representation, but
two types with the same representation may or may not be compatible.

char, signed char, and unsigned char are all mutually incompatible, even
though two of them are guaranteed to have the same representation.

If you want to talk about types having the same representation, feel
free to do so, but please don't use the defined technical term
"compatible" to do so.

I don't buy the nonsense in the standard that the member names must
match; what possible difference can that make?

Too bad.  That's what the standard says.  And it make sense if you
understand that compatibility isn't (just) about representation.

If you write:

int main(void) {
    struct { double x_in_feet;   double y_in_feet;   } u = { 1.0, 1.0 };
    struct { double x_in_meters; double y_in_meters; } m;
    m = u;
}

do you think a compiler should accept the assignment without complaint?

(In practice I'd use distinct tags for both types, but the standard has
to specify what happens if the tags aren't given.)

[...]

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.

OK, I'll explain what's going on.  There was a discussion about two
C types.  Two people disagreed about whether they're compatible
or not.  I care about how C defines type compatibility, but I do
not care about those specific two types.  Why should I?

People make mistakes.  It happens.  It certainly happens to me.

If I did care, I could dig through the thread and find the exact
types they were talking about, but I couldn't be 100% certain that
I was looking at the same types, in the same context, that they
were discussing.

I usually don't spend this much time talking about things I don't
care about (again, those specific two types, not the meaning of
compatibility), but in this case you insist that I should care and
have made up something about someone saying they were both right.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */