Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: <8634enhcui.fsf@linuxsc.com> <86ldsdfocs.fsf@linuxsc.com> <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com> <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com> <20250407210248.00006457@yahoo.com> 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: 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.