Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Tue, 8 Apr 2025 22:56:59 -0700
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <vt527b$nsu$2@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> <vt4del$3a9sk$1@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 07:57:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d6b678eb7e1d3f498ba97e7a21a9aa05";
	logging-data="24478"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+yLsOGrS6xN/1AQmw7dgTjWjWU56xWURA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:3j42EWafb1VnVeYBMBSZkzuGj58=
In-Reply-To: <vt4del$3a9sk$1@dont-email.me>
Content-Language: en-US

On 4/8/2025 5:02 PM, bart wrote:
> 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.
> 
> 
> 

If your lang can support something akin to GLM out of the box, that 
would be fun. Akin to GLSL shaders...