Deutsch   English   Français   Italiano  
<vt4del$3a9sk$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Wed, 9 Apr 2025 01:02:29 +0100
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <vt4del$3a9sk$1@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>
 <868qoaeezc.fsf@linuxsc.com> <vt3oeo$2oq3p$1@dont-email.me>
 <86mscqcpy1.fsf@linuxsc.com> <vt48go$35hh3$2@dont-email.me>
 <86iknecjz8.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 09 Apr 2025 02:02:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="86cd0c292c528f4b59336ead25869004";
	logging-data="3483540"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+M/cIa/yuwvL7tmMhsVCM9"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FESpteruxKMOgvhEfDFxPfAlLD4=
In-Reply-To: <86iknecjz8.fsf@linuxsc.com>
Content-Language: en-GB
Bytes: 4292

On 09/04/2025 00:27, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:

>>> If you want to make a point or ask a question about C code,
>>> SHOW THE CODE.  And show all of it.  Don't make people guess
>>> by showing only some of the code or by giving just a description.
>>
>> I'm showing the code but you keep snipping it!  [...]
> 
> No, I don't.  Don't be so obtuse.  I included the code I was
> originally commenting on, in my first followup.  My comment about
> showing code was about your second posting.  Let me repeat the two
> important paragraphs (quoted above) taken from that posting:
> 
>>>> I get an incompatible error (from the example you snipped) even when I
>>>> remove both struct tags.
> 
> The phrase "even when I remove both struct tags" describes code, it
> doesn't show the code.

I showed this example a few lines later which has both struct tags omitted:

BC:
 > Two typedefs for same struct layout appear to create distinct types;
 > this fails:
 >
 >    typedef struct {float x, y;} Point;
 >    typedef struct {float x, y;} vector;
 >
 >    Point p;
 >    vector v;
 >
 >    p=v;


But before I get there, I say:

 > I can't use the same struct tag in the same scope as one will clash with
 > the other.

That would be something like this:

     typedef struct tag {float x, y;} Point;
     typedef struct tag {float x, y;} vector;

I suggested:


 > But if I have the second in an inner scope, then I again get
 > the error.

That would be something like this where both 'struct tag' can co-exist:

     typedef struct tag {float x, y;} Point;
     {
        typedef struct tag {float x, y;} vector;
        ... rest of example that assigns v to p
     }



You asserted that the incompabilities are due to the struct tags. I 
tried various tests but couldn't find any evidence for that. The structs 
are incompatible, even though they have identical layout, member names 
and structs, because they distinct, as demonstrated by the first example 
in this post. (That needs to be inside any function to see that error.)

That makes sense to me, since different structs even with the same 
members could be intended for any number of unrelated purposes:

  typedef struct (float a, b, c;} rgbfloat;
  typedef struct (float a, b, c;} point;
  typedef struct (float a, b, c;} vector;
  typedef struct (float a, b, c;} circle;
  typedef struct (float a, b, c;} poly;

You wouldn't want instances to these to be assigned to each other 
willy-nilly, or passed to functions expectong one of the other functions.

Yes, you'd probably use better names, but AFAIK your choice of member 
names shouldn't play a part in determining compatibility.