Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Wed, 9 Apr 2025 14:36:15 +0200
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <vt5pjv$inuo$5@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <8634enhcui.fsf@linuxsc.com>
 <vsph6b$ce6m$5@dont-email.me> <86ldsdfocs.fsf@linuxsc.com>
 <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com>
 <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>
 <vt5fed$ccri$1@dont-email.me> <vt5jfo$e5qu$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 09 Apr 2025 14:36:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="39048323a720df50869558e92437b3ec";
	logging-data="614360"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+1ms5V1FZ14jitmAmxYfmh0tSXT5/2H34="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:raS6a0pEO+dsSbd+vXeOKywUfKw=
Content-Language: en-GB
In-Reply-To: <vt5jfo$e5qu$4@dont-email.me>
Bytes: 5764

On 09/04/2025 12:51, bart wrote:
> On 09/04/2025 10:42, David Brown wrote:
>> On 08/04/2025 18:28, bart wrote:
>>> On 08/04/2025 15:50, David Brown wrote:
> 
>>>> The two types are entirely compatible. 
>>>
>>>
>>> Are they?
>>
>> Yes.
>>
>>> So why does gcc report an error here (the two types are from my 
>>> example):
>>>
>>>    typedef struct point {float a; float b;} Point;
>>>
>>>    typedef float length;
>>>    typedef struct _tag {length x, y;} vector;
>>>
>>>    Point p;
>>>    vector v;
>>>
>>>    p=v;
>>>
>>> c.c:14:5: error: incompatible types when assigning to type 'Point' 
>>> {aka 'struct point'} from type
>>> ector' {aka 'struct _tag'}
>>>     14 |   p=v;
>>>        |     ^
>>>
>>
>> That is a different situation.  In the first case, the types were 
>> defined in different translation units - and are compatible.  In the 
>> second case, they are within the same translation unit, and are not 
>> compatible.
> 
> This doesn't make sense at all.
> 
> Turning it around, you're saying that if T an U are incompatible types 
> within the same translation unit, they suddenly become compatible if 
> split across two translation units?
> 

In the specific case of structs and unions matching the requirements in 
6.2.7, yes.  /Please/ read that section of the standard before making 
any more posts about it.

There are plenty of differences between compiling two C files 
independently, and pasting them directly together in one file and 
compiling that.  This is one of those differences.

> 
>> In C, if you declare two structs in the same translation unit with the 
>> same field types and the same field names, they are still different 
>> types.  That is important for making new types - it is how you get 
>> strong typing in C (albeit with less user convenience than in some 
>> other languages).  It means that you can't mix up two types just 
>> because of coincidences in the fields.
>>
>> This means that when you have a struct declaration in two translation 
>> units (locally in the C file, or via a header file - there is no 
>> distinction), they form two different types as they are separate 
>> declarations.  If C did not specify that these were compatible, it 
>> would be impossible (without UB) to use struct or union types across 
>> translation units.
> 
> So, yes, you are saying that. In short, if a programmer says that 
> incompatible types T and U are the same (where the compiler can only see 
> T in module A and U in module B), then the programmer must be trusted, 
> even though they would be wrong.
> 

Yes.

> Note that I, as the programmer, said this:
> 
> "The types involved are somewhat different, but are compatible enough 
> for it to work."
> 

It's not quite like that - C says that although they are different types 
(since they are in different translation units), they are compatible in 
this situation.  Not "compatible enough to work", but /actually/ 
compatible in the specific C technical sense.  (Section 6.2.7 has 
"compatible type" in italics - it defines what is meant by that term in 
the C language.)


> What you are saying is that even though I was actually telling the 
> truth, I was wrong. But I would be right if I lied about it....
> 

No, you were not telling the truth - you were wildly mixing things.

> We're either through the Looking-Glass at this point, or somewhere not 
> in Kansas!
> 
> I'll have to think about this before replying to any other points.

Marvellous - I'd appreciate you putting more thought into this, and less 
knee-jerk reactions and exaggerations.  Please also read the relevant 
parts of the standards before replying - at the very least, section 
6.2.7p1 and section 6.2.2.  Once you have read these and tried to 
understand them, it will be a lot easier to clear up any remaining issues.

> 
>> You are still wrong.
> 
> Never mind. I've just spotted this at the end. In that case, and given 
> what you said above where you arguing that Black is White, discussion is 
> futile.
> 

I believe there is still hope.  But it does require you to read and think.