Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Thu, 10 Apr 2025 21:20:17 -0700
Organization: None to speak of
Lines: 87
Message-ID: <87jz7rtjlq.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$1@dont-email.me> <20250406190321.000001dc@yahoo.com>
	<86plhodtsw.fsf@linuxsc.com> <20250407210248.00006457@yahoo.com>
	<vt15lq$bjs0$3@dont-email.me> <vt2lp6$1qtjd$1@dont-email.me>
	<vt31m5$2513i$1@dont-email.me> <vt3d4g$2djqe$1@dont-email.me>
	<vt3iqh$2ka99$1@dont-email.me> <868qoaeezc.fsf@linuxsc.com>
	<vt3oeo$2oq3p$1@dont-email.me> <86mscqcpy1.fsf@linuxsc.com>
	<vt48go$35hh3$2@dont-email.me> <86iknecjz8.fsf@linuxsc.com>
	<vt4del$3a9sk$1@dont-email.me> <86o6x5at05.fsf@linuxsc.com>
	<vt712u$1m84p$1@dont-email.me> <20250409170901.947@kylheku.com>
	<vt88bk$2rv8r$1@dont-email.me> <20250410092409.825@kylheku.com>
	<vt9334$3hhr8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Apr 2025 06:22:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c7132c9dc01e9da84b004e8ef39b7407";
	logging-data="662889"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Z/IByoHqZYJQ5qH1Pa0TG"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:7hb5Uftoxjce1Hm0775wd0TE94I=
	sha1:Wuuyi6lQex10wnKsryG5lWM17zs=
Bytes: 5156

bart <bc@freeuk.com> writes:
> On 10/04/2025 17:51, Kaz Kylheku wrote:
>> On 2025-04-10, bart <bc@freeuk.com> wrote:
>
>>> Do you agree with that? Or is there something more to making two types
>>> be incompatible?
>> Tim: two fingerprints from the left hand index finger are from
>> different
>> humans if they are different.
>> You: do you agree with this, or is there more that can make
>> two humans different?
>> Struct compatibility is determined by tag and content.
>
> This is more nuanced. There is two structs being the same type or not,
> which a compiler can determine if they are in the same translation
> unit; no need to analyse tags or anything to figure that out, it's
> either the exact same type or not.
>
> And there is two structs in two translation units which have separate
> definitions, which the compiler cannot compare, and which have to be
> compatible for the program to be valid. But the compiler cannot check
> that.
>
> The example was like this:
>
> module A:     typedef struct point {float a; float b;} Point;
>
> module B:     typedef float length;
>               typedef struct _tag {length x, y;} vector;

I know I said I didn't care about the specific types, but now that I've
seen a concise example (via a followup someone else posted), I've
decided to take a look.  I'm allowed to change my mind.

I'll assume that "module A" and "module B" mean that the two
declarations are in different translation units.  I'll assume that
the declarations are *exactly* like the above.  I won't assume
anything about whether the above example accurately reflects the
types that were discussed earlier.

My reading of the standard is that the two types are clearly *not*
compatible.  (Irrelevantly, they're very likely to have the same
representation.)

I'll refer to the N3096 draft of C23, section 6.2.7.  I don't think
other editions give different answers.

Two complete struct types *with the same tag* are compatible if
they meet certain requirements.  These types have different tags,
"point" and "_tag", so those requirements are irrelevant here.

    Furthermore, two structure, union, or enumerated types declared in
    separate translation units are compatible in the following cases:

    - both are declared without tags and they fulfill the requirements
      above;
      
    — both have the same tag and are completed somewhere in their
      respective translation units and they fulfill the requirements above;

    — both have the same tag and at least one of the two types is not
      completed in its translation unit.

None of these three bullet points applies to types with different tags
*or* to types with different member names (a, b vs. x, y).

    Otherwise, the structure, union, or enumerated types are
    incompatible.

Conclusion: They're incompatible.

Two regular users commented on *some* pair of types and disagreed
on whether they're compatible.  I won't comment here on who was
correct, because I don't know whether they were talking about the
types quoted above.

[...]

Practically, if you need two translation units to use compatible struct
types, you should define the type in a shared header.  That guarantees
(assuming no nasty tricks are played before the #include directive) that
the types have the same tag, and the same member names and types in the
same order.

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