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: Fri, 11 Apr 2025 14:10:35 -0700
Organization: None to speak of
Lines: 33
Message-ID: <87o6x2qu9g.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$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>
	<87wmbs45oa.fsf@nosuchdomain.example.com>
	<vt8hdp$333f0$1@dont-email.me>
	<87semf4pw5.fsf@nosuchdomain.example.com>
	<vt9let$4au3$1@dont-email.me>
	<87zfgn344c.fsf@nosuchdomain.example.com>
	<20250411142636.00006c00@yahoo.com> <20250411102119.431@kylheku.com>
	<vtbriv$2e8u2$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 23:10:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c7132c9dc01e9da84b004e8ef39b7407";
	logging-data="2761812"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Ds8axgc84hbqRxvUWTrUi"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:J6pGB/XQL5OIncQanVA3wZ1hMYE=
	sha1:sAhqbrKhBepJcvrNcJAjxIe268Y=
Bytes: 3073

bart <bc@freeuk.com> writes:
[...]
> What about struct {long x;} and struct {int64_t x;}?
>
> Whether they are compatible seems to be depend on platform.
>
> Or rather, whether or not int64_t happens to defined on top of 'long'
> or 'long long'.

Correct.  If long is 32 bits, they're not compatible.  If long
is 64 bits and int64_t is a typedef for long, they're compatible.
If long is 64 bits and int64_t is a typedef for long long (or for
a 64-bit extended integer type) they're not compatible.

Again, type compatibility isn't just about representation.

And again, I am describing how C is defined, not advocating or
defending it.

If you're working with code where the compatibility of those two
types matters, it's probably best to modify the code to use a
single type, defined in a shared header if it's used in more than
one translation unit.  If that's not practical and you're sure the
types have the same representation, you can probably work around it
with some kind of type-punning (pointer casts, unions, memcpy()),
though some such workarounds might involve undefined behavior.
Or you can just copy the x member from an object of one type to an
object of the other type (there's an implicit conversion between
long and int64_t whether they're compatible or not).

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