On 2025-04-10, bart <
bc@freeuk.com> wrote:
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."
That is true. If we know that two struct types have tags obtained
from the source code declaration, and those tags are different,
they are necessarily incompatible types, regardless of whether
they are in the same translation unit or different ones.
Do you agree with that? Or is there something more to making two types
be incompatible?
Tim: two fingerprints from the left hand index finger are from different
humans if they are different.
You: do you agree with this, or is there more that can make
two humans different?
Struct compatibility is determined by tag and content.
My examples included ones where tags /were/ different; tags which were
identical (in nested scopes) and tags which were missing.
tags which are identical do not speak to the situation of tags not
being identical.
My view is that even if type discrimination was 100% dependent on tags,
Given the logical statement P and Q would you say that it its
truth is 50% dependent on P and 50% on Q?
I would say that it's 100% dependent on P, and 100% on Q. :)
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.
It's completely relevant to the problem of pretending that there is
no gravity just because it doesn't appear in the construction
syntax.
>
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?
Because then you're still caring about what someone wrote in
comp.lang.c, which could be unreliable.
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.
How can it not?
struct tag;
struct tag { ... };
these have to refer to the same type; how do you do that without 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:
This is correct; but if the defining body were omitted from the fourth
one, it would have to refer to the previous declaration upscope by tag
matching.
In separate lexical scopes, we can have structs that are completely
different (different shape) and have the same tag.
As far as different translation units go, there are rules. But most
implementations of C operate on faith: implementations see only
the type declarations in one translation unit being processed.
It is trusted that cross-translation-unit uses of types are compatible.
In most C implementations, there is /de facto/ structural compatibility
in that two structures in separate units can have different tags,
and different member names, used to alias the same object, will not
cause any problem. The ISO C rules are stricter. The tags have
to be the same as well as the names of corresponding struct members
that have names.
Additionally, there is this rule: two structs defined in separate
translation units, each without a tag, but otherwise the same
(same member names in same order, same types, alignment, ...)
are compatible! This is even though they would not be compatible
if they appeared in the same translation unit.
This is something that will Just Work in implementations that don't care
about tags across translation units.
Another rule, much more obvious, is that if a struct in one translation
unit is incomplete, and complete in another translation unit, and they
have the same tag, then they are compatible. Obviously this is
exploited in every program that uses incomplete structs in header files
for opaque types.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca
do { quit; } else { }
Re: do { quit; } else { }