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: Thu, 10 Apr 2025 12:00:03 +0100
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <vt88bk$2rv8r$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> <vt4del$3a9sk$1@dont-email.me>
 <86o6x5at05.fsf@linuxsc.com> <vt712u$1m84p$1@dont-email.me>
 <20250409170901.947@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Apr 2025 13:00:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d4d34b1d7ed35db6137f2b3fedef19a1";
	logging-data="3013915"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EY8ly9M0v+XFfNNOZdrHc"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sbuDkYX59eQ4N9eRvang1C/6VZg=
In-Reply-To: <20250409170901.947@kylheku.com>
Content-Language: en-GB
Bytes: 5378

On 10/04/2025 01:20, Kaz Kylheku wrote:
> On 2025-04-09, bart <bc@freeuk.com> wrote:
>> I'm not sure what your gripe is other than maybe I picked up on
>> something you got wrong. The discussion was about two struct types like
>> this:
>>
>>      typedef struct tag1 {...} T1;
>>      typedef struct tag2 {...} T2;
>>
>> and whether T1 and T2 were compatible or not. You said:
>>
>> "and those types are not compatible, because the two struct tags are
>> different."
>>
>> In this case the tags would be "tag1" and "tag2". I then said:
>>
>> "I get an incompatible error (from the example you snipped) even when I
>> remove both struct tags."
> 
> When you remove the tag from a struct definition, the implementation
> behaves as if it were implementing a unique tag which is different
> from any other such tag, and any tag that can possibly be written
> using textual syntax.
> 
> How did you implement tagless struct declarations in your compiler?
> 
>> That means removing "tag1" and "tag2" so the example above looks like this:
>>
>>      typedef struct {...} T1;
>>      typedef struct {...} T2;
>>
>> Here, you can't say the struct tags are different, as they are not
>> visible!
> 
> So if you close your eyes, two things that were different are now
> no longer different, since they are invisible?
> 
> The tag is a property of the type, not of printed type declaration.

Someone, not anyone but the all-knowing Tim, said: "and those types are 
not compatible, because the two struct tags are different."

Do you agree with that? Or is there something more to making two types 
be incompatible?

My examples included ones where tags /were/ different; tags which were 
identical (in nested scopes) and tags which were missing.

My view is that even if type discrimination was 100% dependent on tags, 
then it would be poor to rely on something which can be invisible in 
source code (either tags don't exist, or they appear identical).



> A struct type has a tag. If the declaration doesn't show one,
> that doesn't mean it doesn't have a tag.
> 
> If a "Simulation" object has a "gravity" member, do you conclude
> that a given simulation has no gravity, because the constructor
> omitted specifying it?
> 
>    Simulation s = new Simulation(windSpeed = 35.7)

This is quite irrelevant, since 'gravity' will be defined somewhere in 
the source code, but you are talking about some internal attribute that 
may or may not be used by an implementation.

>> As I concluded, your assertion about compatibility being based on tags
>> being the same or not didn't seem right.)
> 
> Or, you know, you could stop caring about what someone wrote in
> comp.lang.c, be they right or wrong, and ... look it up?

Why don't you just tell me?

In my C compiler, each type has a unique index which is what is compared 
to see if two types are the same type. It has nothing to do with tags.

This C code:

     struct     {int x;};
     struct     {int x;};
     struct Tag {int x;};
     {struct Tag {int x;};}

Produces these 4 distinct types, with indices 23-26:

   23 struct (i32 x)
      Name: struct $T1
      Def:  03C24580 $T1.1          # .1 etc is a block scope index

   24 struct (i32 x)
      Name: struct $T2
      Def:  03C246C0 $T2.1

   25 struct (i32 x)
      Name: struct Tag
      Def:  03C247F0 Tag.1

   26 struct (i32 x)
      Name: struct Tag
      Def:  038D2910 Tag.2

The types without tags will have an internal tag supplied, since each 
user type is required to have an ST entry. But it is the 23/24/25/26 
that is used in the type system to discriminate between them.