Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Fri, 11 Apr 2025 20:46:39 +0100
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <vtbriv$2e8u2$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <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> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 11 Apr 2025 21:46:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dd2082d654358406b52b51744c06eb0c";
	logging-data="2565058"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18lQ1l3UMZ0tJIbvVYtCyHz"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:WJX0btBes0JScii46Q9I7iQcZdI=
Content-Language: en-GB
In-Reply-To: <20250411102119.431@kylheku.com>
Bytes: 2834

On 11/04/2025 18:22, Kaz Kylheku wrote:
> On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
>> On Thu, 10 Apr 2025 17:59:15 -0700
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>>
>>> An understanding of what "compatible types" means.
>>
>> Bart didn't say that types are compatible or non-compatible.
>> He said that they are 'compatible enough'. That is not terminology of C
>> Standard, but terminology of his own. And he seems to understand it.
>>
>> In my own translation, 'compatible enough' means that when these structs
>> are accessed then any sane or even semi-sane compiler will generate code
>> that will have the same effect as in case of access through structures
>> with literally identical declarations.
> 
> so struct { long x; } and struct { int x; } are compatible enough,
> in situations that are portable enough.


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'.