Does anyone know or can see a reason why the C language makes
distinction between identical struct types?

Like this:

void F(struct {int i; }* p){}

int main() {
struct { int i; } s;
F(&s);
}

Compare with functions:

void F(void (*pf)(void)){}
void F2(void) {}
int main()
{ void (*pf)(void) = F2;
F(pf);
}

Must be something with padding?
But why, we are inside the same compiler?
How safe we are doing a cast?

On 10/07/2021 13:41, Thiago Adams wrote:
> Does anyone know or can see a reason why the C language makes
> distinction between identical struct types?
>
> Like this:
>
> void F(struct {int i; }* p){}
>
> int main() {
> struct { int i; } s;
> F(&s);
> }
>
> Compare with functions:
>
> void F(void (*pf)(void)){}
> void F2(void) {}
> int main()
> {
> void (*pf)(void) = F2;
> F(pf);
> }
>
> Must be something with padding?
> But why, we are inside the same compiler?
> How safe we are doing a cast?
>
>

What's the algorithm for determining whether two structs are compatible?

It would need to deal with differently named fields, locally defined
types, local values of pack(), anonymous unions etc.

However, some want to use structs in order to enforce type protection
especially when the contents have an identical layout.

On Saturday, July 10, 2021 at 9:59:08 AM UTC-3, Bart wrote:
> On 10/07/2021 13:41, Thiago Adams wrote:
> > Does anyone know or can see a reason why the C language makes
> > distinction between identical struct types?
> >
> > Like this:
> >
> > void F(struct {int i; }* p){}
> >
> > int main() {
> > struct { int i; } s;
> > F(&s);
> > }
> >
> > Compare with functions:
> >
> > void F(void (*pf)(void)){}
> > void F2(void) {}
> > int main()
> > {
> > void (*pf)(void) = F2;
> > F(pf);
> > }
> >
> > Must be something with padding?
> > But why, we are inside the same compiler?
> > How safe we are doing a cast?
> >
> >
> What's the algorithm for determining whether two structs are compatible?
Ignore all spaces for instance and compare attributes. In this case the type,
name and order of the members must match.
> It would need to deal with differently named fields, locally defined
> types, local values of pack(), anonymous unions etc.

One justification could possible be just because this is simple to do?
> However, some want to use structs in order to enforce type protection
> especially when the contents have an identical layout.

This justification maybe is applied to typedefs? Using typedefs different types
are compatible if they have the same layout (underline type). (like BOOL and int)

I did some samples with enums:

enum {A, B} F(void) { return A;}
enum {A, B} F2(void) { return B; }

compilers generates an error of redefinition for the enum.

This is fine:

enum {A, B} F(void) {
return B;
}

int main(){
if (F() == A) { }
}

But this is an error:

void F(enum {A, B} e) {}
int main() {
F(A);
}

and this
void F(enum {A, B} e) {}
void F2(enum {A, B} e) {}
is a warning

This is just curiosity.

In other topics I already said that this could be useful
to create parametrized structs using macros.

for instance:
void F(dynamic_array(int)* a){}

Maybe the word extern could be used to create this feature
without breaking compatibly.

void F(extern struct { int* data; int size, capacity; } * a){
}

On 10/07/2021 16:14, Thiago Adams wrote:
> On Saturday, July 10, 2021 at 9:59:08 AM UTC-3, Bart wrote:
>> On 10/07/2021 13:41, Thiago Adams wrote:
>>> Does anyone know or can see a reason why the C language makes
>>> distinction between identical struct types?
>>>
>>> Like this:
>>>
>>> void F(struct {int i; }* p){}
>>>
>>> int main() {
>>> struct { int i; } s;
>>> F(&s);
>>> }
>>>
>>> Compare with functions:
>>>
>>> void F(void (*pf)(void)){}
>>> void F2(void) {}
>>> int main()
>>> {
>>> void (*pf)(void) = F2;
>>> F(pf);
>>> }
>>>
>>> Must be something with padding?
>>> But why, we are inside the same compiler?
>>> How safe we are doing a cast?
>>>
>>>
>> What's the algorithm for determining whether two structs are compatible?

> Ignore all spaces for instance and compare attributes. In this case the type,
> name and order of the members must match.

Are you talking about comparing /source code/?

Anyway it's debatable whether member names must match. For the purposes
of copying struct A to struct B, only layout and types need to match.

Member names are only important when accessing members by name:

struct A {int x;} i;
struct B {int y;} j;

struct A* p;

p = &j; // should this be allowed?
p -> y; // but this can't be

>> It would need to deal with differently named fields, locally defined
>> types, local values of pack(), anonymous unions etc.
> One justification could possible be just because this is simple to do?

I haven't tried so don't know all the pitfalls. It would be a recursive
process that needs to deal with nested structs, also with pointers to
structs that may be compatible.

>> However, some want to use structs in order to enforce type protection
>> especially when the contents have an identical layout.
>
> This justification maybe is applied to typedefs?

In C, a typedef does not create a distinct type.

> Using typedefs different types
> are compatible if they have the same layout (underline type). (like BOOL and int)
>
> I did some samples with enums:
>
> enum {A, B} F(void) { return A;}
> enum {A, B} F2(void) { return B; }
>
> compilers generates an error of redefinition for the enum.

Because A and B exist in the same namespace as normal identifiers, so
here they clash.

> This is fine:
>
> enum {A, B} F(void) {
> return B;
> }
>
> int main(){
> if (F() == A) { }
> }
>
> But this is an error:
>
> void F(enum {A, B} e) {}
> int main() {
> F(A);
> }

Because A exists only in the scope of F.

> and this
> void F(enum {A, B} e) {}
> void F2(enum {A, B} e) {}
> is a warning

I guess this is the same warning you would have got in the last example?
(As well as the error due to undefined A.)

> This is just curiosity.
>
> In other topics I already said that this could be useful
> to create parametrized structs using macros.
>
> for instance:
> void F(dynamic_array(int)* a){}
>
> Maybe the word extern could be used to create this feature
> without breaking compatibly.
>
> void F(extern struct { int* data; int size, capacity; } * a){
> }
>

Personally I don't like in-place struct definitions at all.

Define user types by themselves. Then use the new type in variable and
parameter lists.

In any case, if a struct is to be shared, you only really want one
definition of it, in a place where it visible to all code that will use it.

Thiago Adams <thiago.adams@gmail.com> writes:
>void F(struct {int i; }* p){}
....
> struct { int i; } s;

The presence of a struct-declaration-list in a
struct-or-union-specifier declares a new type,
within a translation unit.

This enables a programmer to specify different
struct types with the same layout but different
semantics.

Bart wrote:
> On 10/07/2021 16:14, Thiago Adams wrote:
>> On Saturday, July 10, 2021 at 9:59:08 AM UTC-3, Bart wrote:
>>> On 10/07/2021 13:41, Thiago Adams wrote:
>>>> Does anyone know or can see a reason why the C language makes
>>>> distinction between identical struct types?
>>>>
>>>> Like this:
>>>>
>>>> void F(struct {int i; }* p){}
>>>>
>>>> int main() {
>>>> struct { int i; } s;
>>>> F(&s);
>>>> }
>>>>
>>>> Compare with functions:
>>>>
>>>> void F(void (*pf)(void)){}
>>>> void F2(void) {}
>>>> int main()
>>>> {
>>>> void (*pf)(void) = F2;
>>>> F(pf);
>>>> }
>>>>
>>>> Must be something with padding?
>>>> But why, we are inside the same compiler?
>>>> How safe we are doing a cast?
>>>>
>>>>
>>> What's the algorithm for determining whether two structs are compatible?
>
>> Ignore all spaces for instance and compare attributes. In this case
>> the type,
>> name and order of the members must match.
>
>
> Are you talking about comparing /source code/?

Not exactly. Let's say some pragma affects the struct layout.
The compiler has it own way to compare internally.

> Anyway it's debatable whether member names must match. For the purposes
> of copying struct A to struct B, only layout and types need to match.
>
> Member names are only important when accessing members by name:
>
>     struct A {int x;} i;
>     struct B {int y;} j;
>
>     struct A* p;
>
>     p = &j;         // should this be allowed?
>     p -> y;         // but this can't be
>
>>> It would need to deal with differently named fields, locally defined
>>> types, local values of pack(), anonymous unions etc.
>> One justification could possible be just because this is simple to do?
>
> I haven't tried so don't know all the pitfalls. It would be a recursive
> process that needs to deal with nested structs, also with pointers to
> structs that may be compatible.

Sorry I wasn't clear..I mean some decisions made for the C language may
be because they are the easiest way to implement. So maybe avoiding
this extra check for struct layout is the easiest/fastest way.

>>> However, some want to use structs in order to enforce type protection
>>> especially when the contents have an identical layout.
>>
>> This justification maybe is applied to typedefs?
>
> In C, a typedef does not create a distinct type.
>
>> Using typedefs different types
>> are compatible if they have the same layout (underline type). (like
>> BOOL and int)

Using the same reasoning of the easiest path for structs, maybe this
was also the easiest way to implement typedefs but in this case not
making them proper types.

>> I did some samples with enums:
>>
>> enum {A, B} F(void) {  return A;}
>> enum {A, B} F2(void) {   return B; }
>>
>> compilers generates an error of  redefinition for the enum.
>
> Because A and B exist in the same namespace as normal identifiers, so
> here they clash.
>
>
>> This is fine:
>>
>> enum {A, B} F(void) {
>>      return B;
>> }
>>
>> int main(){
>>      if (F() == A)  { }
>> }
>>
>> But this is an error:
>>
>> void F(enum {A, B} e) {}
>> int main() {
>>      F(A);
>> }
>
> Because A exists only in the scope of F.
>
>
>> and this
>> void F(enum {A, B} e) {}
>> void F2(enum {A, B} e) {}
>> is a warning
>
> I guess this is the same warning you would have got in the last example?
> (As well as the error due to undefined A.)

The "rule" is that types defined on function return are global
but function parameters works like the types were inside the
function.

Something that may make sense with the old parameter declaration
style and very confusing now. Because someone must call the function
then the parameter type must be public but it is not.

>> This is just curiosity.
>>
>> In other topics I already said that this could be useful
>> to create parametrized structs using macros.
>>
>> for instance:
>> void F(dynamic_array(int)* a){}
>>
>> Maybe the word extern could be used to create this feature
>> without breaking compatibly.
>>
>> void F(extern struct { int* data; int size, capacity; } * a){
>> }
>>
>
> Personally I don't like in-place struct definitions at all.

The argument I have is that some types does not need names. Names
just make them less readable and just remove information.

For comparison, assume each time you use a C array you have
to declare a name.

For instance instead of

void F(int ar[])

you need

void F(int_array* a);

This is exactly what happened when we use dynamic arrays
in C. We need a name for them and it is impossible to know
what it does without looking at the details.
Differently of int a[] that we know the semantics.
With parametrized types we know the semantics without adding
these extra names.

On 7/10/2021 5:41 AM, Thiago Adams wrote:
> Does anyone know or can see a reason why the C language makes
> distinction between identical struct types?

Because in C a struct declaration is a type declaration, which
introduces a new named type `struct <tag>`.

> Compare with functions:
>
> void F(void (*pf)(void)){}

Syntactic constructs that describe function type (or function pointer
type) are not type declarations. They do not introduce new named types.

That's the critical distinction between the two.

> Like this:
>
> void F(struct {int i; }* p){}
>
> int main() {
> struct { int i; } s;
> F(&s);
> }
>

Your example is an odd one: you omitted the struct tag. This is legal
but this provides no special treatment for that struct declaration. It
still declares a new type, which just happens to be tagless.
Nevertheless, two identical struct declarations, named or not, declare
two different types.

> Must be something with padding?

Nope. Why?

> But why, we are inside the same compiler?

Because that's how the language is defined.

Things get more loose one we start talking about type compatibility
across different translation units, for obvious reasons. But in the same
translation unit it is pretty strict.

--
Best regards,
Andrey Tarasevich

On Saturday, 10 July 2021 at 13:41:07 UTC+1, Thiago Adams wrote:
> Does anyone know or can see a reason why the C language makes
> distinction between identical struct types?
>
A point and a vector both have the same fields.
However if you declare both a struct point and a struct vector in the
same program, then presumably you want to enforce the distiction
between them. Subtracting two points yields a vector, for example.

So you won't want the language to allow you to override that
distinction too easily.

On 10/07/2021 20:28, Thiago Adams wrote:
> Bart wrote:
>> On 10/07/2021 16:14, Thiago Adams wrote:

>>> Using typedefs different types
>>> are compatible if they have the same layout (underline type). (like
>>> BOOL and int)
>
> Using the same reasoning of the easiest path for structs, maybe this
> was also the easiest way to implement typedefs but in this case not
> making them proper types.

Making them proper types is a big deal. Before you know it, you will
have to implement half of C++ or Ada to deal with type hierarchies,
inheritance and the rest:

typedef int T;
typedef int U;

T a; U b;

What happens with a+b; should it be allowed, what does it mean, and what
is the result type? What about a+1?

>> I guess this is the same warning you would have got in the last
>> example? (As well as the error due to undefined A.)
>
>
>
> The "rule" is that types defined on function return are global
> but function parameters works like the types were inside the
> function.
>
> Something that may make sense with the old parameter declaration
> style and very confusing now. Because someone must call the function
> then the parameter type must be public but it is not.

The parameter list is not really public, but is accessible to the compiler.

New types with associated names (structs/enums) constructed inside a
parameter list are also accessible to the compiler, but it needs the
names to check compatibility, and those names have to be resolved within
normal scope rules.

My view is that it was silly to allow such types to be created inside a
parameter list.

>> Personally I don't like in-place struct definitions at all.
>
> The argument I have is that some types does not need names. Names
> just make them less readable and just remove information.
>
> For comparison, assume each time you use a C array you have
> to declare a name.
>
> For instance instead of
>
> void F(int ar[])
>
> you need
>
> void F(int_array* a);
>
> This is exactly what happened when we use dynamic arrays
> in C. We need a name for them and it is impossible to know
> what it does without looking at the details.
> Differently of int a[] that we know the semantics.
> With parametrized types we know the semantics without adding
> these extra names.

C allows you to construct new types using * and [] modifiers. Those do
not involve new identifiers, so you don't have the problem of scope to
contend with.

You can also construct function types using () modifiers. There the
names of the parameters are optional, but are not accessible from C code
so it doesn't matter.

But struct{} and enum{} types do involve adding new identifiers which
may be necessary to access in order to use the type. Then you have the
problem of scope.

This is why it makes sense to formally define such types outside a
function, in global scope, where they are fully visible.

After all a struct{} or enum{} type may involve dozens (or hundreds) of
lines and new identifiers, not like a type like 'int(*)[]' which
occupies a fraction of a line, is anonymous, and so more suitable for
constructing in-line.

On Saturday, July 10, 2021 at 8:41:07 AM UTC-4, Thiago Adams wrote:
> Does anyone know or can see a reason why the C language makes
> distinction between identical struct types?
>
> Like this:
>
> void F(struct {int i; }* p){}
>
> int main() {
> struct { int i; } s;
> F(&s);
> }
>
> Compare with functions:
>
> void F(void (*pf)(void)){}
> void F2(void) {}
> int main()
> {
> void (*pf)(void) = F2;
> F(pf);
> }
>
> Must be something with padding?
> But why, we are inside the same compiler?
> How safe we are doing a cast?

First, what the relevant rules are: The key point is that
"The presence of a struct-declaration-list in a struct-or-union-specifier
declares a new type, within a translation unit." (6.7.2.1p8).
Note that it is a new type, distinct from any previously declared type,
regardless of whether it has the same layout.

In many places, the standard imposes a constraint that two types be
compatible, or declares the behaviour is undefined if they aren't. Two
types are, in general, incompatible unless the standard explicitly says
otherwise. The only such statement that applies to structure types is:

"... two structure,
union, or enumerated types declared in separate translation units are
compatible if their tags and members satisfy the following
requirements: If one is declared with a tag, the other shall be declared
with the same tag. If both are completed anywhere within their
respective translation units, then the following additional
requirements apply: there shall be a one-to-one correspondence
between their members such that each pair of corresponding
members are declared with compatible types; if one member of the
pair is declared with an alignment specifier, the other is declared with
an equivalent alignment specifier; and if one member of the pair is
declared with a name, the other is declared with the same name. For
two structures, corresponding members shall be declared in the
same order. For two structures or unions, corresponding bit-fields
shall have the same widths. For two enumerations, corresponding
members shall have the same values." (6.2.7p10).

Note that two different struct types that would be compatible if
declared in separate translation units would not be compatible if
declared in the same translation unit.

The second point is, why? That 6.2.7p10 applies only to "types
declared in separate translation units" is clearly deliberate, it's not
something that could have been written that way due to an
oversight. Well, it's really rather basic. You shouldn't define the
structure of a struct type twice. If you intend to use it in two
different translation units, you satisfy that requirement by defining
that structure in one header file, to be #included into both
translation units, and 6.2.7p10 is what permits that to work. If you
intend to use it in two different locations within a single translation
unit, you have several options for defining it only once:

1. Declare a tag for that type once, and use that tag in all of the
other locations:
struct tag { int i;} a;
struct tag *func(struct tag*);

2. Declare a typedef for the type:
typedef struct { int i;} tag;
tag a;
tag *func(tag *);

3. Declare all objects based upon the type in a single declaration:

struct {int i;} singleItem, array[6], *pointer;

I believe that the reason why 6.2.7p10 is restricted to declarations
in different translation units was that the committee wanted to
make sure you used one of those three alternatives when using
the same struct type in multiple contexts in a single translation
units. Any of those approaches makes it far easier to identify
when two expressions have the same type.

On 7/10/21 7:41 AM, Thiago Adams wrote:
> Does anyone know or can see a reason why the C language makes
> distinction between identical struct types?
>
> Like this:
>
> void F(struct {int i; }* p){}
>
> int main() {
> struct { int i; } s;
> F(&s);
> }
>
> Compare with functions:
>
> void F(void (*pf)(void)){}
> void F2(void) {}
> int main()
> {
> void (*pf)(void) = F2;
> F(pf);
> }
>
> Must be something with padding?
> But why, we are inside the same compiler?
> How safe we are doing a cast?
>
>

You are only allowed to define a give type ONCE in a translation unit.
That is a standard rule in C. The compiler isn't required to check if
two definitions are somehow the same, it is always an error to define a
given type twice.

Thus, you NEVER can have two actual definitions for a given type 'be the
same type'

Note, that while the types aren't the same, and pointers aren't
'compatible' in the sense that you can freely take a pointer to one
become a pointer to the other, the layouts of the two structs must be
the same, as both are layout compatible with a struct defined the same
in another translation unit.

One side effect of this definition rule is that it almost NEVER makes
sense to define an unnamed structure as part of the declaration of
function as you can't ever create thqt type to pass to it. (At best, you
could pass a void* pointer that gets converted to that type).

On Monday, July 12, 2021 at 12:52:13 AM UTC-3, Richard Damon wrote:
> On 7/10/21 7:41 AM, Thiago Adams wrote:
> > Does anyone know or can see a reason why the C language makes
> > distinction between identical struct types?
> >
> > Like this:
> >
> > void F(struct {int i; }* p){}
> >
> > int main() {
> > struct { int i; } s;
> > F(&s);
> > }
> >
> > Compare with functions:
> >
> > void F(void (*pf)(void)){}
> > void F2(void) {}
> > int main()
> > {
> > void (*pf)(void) = F2;
> > F(pf);
> > }
> >
> > Must be something with padding?
> > But why, we are inside the same compiler?
> > How safe we are doing a cast?
> >
> >
> You are only allowed to define a give type ONCE in a translation unit.
> That is a standard rule in C. The compiler isn't required to check if
> two definitions are somehow the same, it is always an error to define a
> given type twice.
>
> Thus, you NEVER can have two actual definitions for a given type 'be the
> same type'
>
> Note, that while the types aren't the same, and pointers aren't
> 'compatible' in the sense that you can freely take a pointer to one
> become a pointer to the other, the layouts of the two structs must be
> the same, as both are layout compatible with a struct defined the same
> in another translation unit.
>
> One side effect of this definition rule is that it almost NEVER makes
> sense to define an unnamed structure as part of the declaration of
> function as you can't ever create thqt type to pass to it. (At best, you
> could pass a void* pointer that gets converted to that type).

There is one proposal to make structs compatible (fount it after
starting this topic.)

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2366.pdf

There are more reasons into this proposal but my motivation to create
parametrized types are included there.

On Saturday, July 10, 2021 at 10:48:02 AM UTC-5, Bart wrote:
> On 10/07/2021 16:14, Thiago Adams wrote:
> > But this is an error:
> >
> > void F(enum {A, B} e) {}
> > int main() {
> > F(A);
> > }
> Because A exists only in the scope of F.
> > and this
> > void F(enum {A, B} e) {}
> > void F2(enum {A, B} e) {}
> > is a warning
> I guess this is the same warning you would have got in the last example?
> (As well as the error due to undefined A.)

It's worse than that. It only exists within the scope of the functions'
argument lists. You can't use it in the bodies of F(), F1(), or F2().