C and its many quirks

[TheCalligrapher]

I'm speaking of the case where an array of some unnamed struct X is defined in a typedef named Y as an array of say 3 elements. In this case there's no way to declare 1, 2, 4, 5 etc arrays of that unnamed struct X should the need ever arise.

If that is your "this", then I agree with you 100%. Defining a tagless/nameless struct type, as shown in your example, definitely does not not look like a good idea. I don't like the fact that I have no way to refer to array element type further down in the code.

To be pedantic, in a pinch it would still possible to refer to the array element type using `decltype` in C++ and `typeof` in the upcoming C23. But I'd personally just give that struct type a tag.

[SiliconWizard]

Here's the Ada question, how does one write this in Ada

Code: [Select]

    struct Info{
        char name[30];
        int age;
        struct address{
            char area_name[39];
            int house_no;
            char district[39];
        };
    };


And bam, that's again a particular case which was absolutely not obvious in your original question. A record inside a record? No problem. But what you actually meant was: an anonymous record. How are we supposed to guess?

Anonymous struct/union members in C have been a GCC extension for a long time, but are non-standard. The standard way was to give the member a name. Just like with other languages.
So instead of something like 'info.house_no' directly, you would have to give the address member a name (eg, 'address'), and access it as 'info.address.house_no'. Same in Ada. Ada has variant records (Pascal had them too IIRC) though, and you can get the somewhat equivalent of "anonymous union members inside a struct" in C.

Anonymous stuct/union members can be elegant in some cases, but one should not abuse them IMO.
And I think - but I'm not 100% sure - they have made their way in the C standard in C23. But that has to be checked, surely. (Was it in C11 even?)

[Sherlock Holmes]

I'm speaking of the case where an array of some unnamed struct X is defined in a typedef named Y as an array of say 3 elements. In this case there's no way to declare 1, 2, 4, 5 etc arrays of that unnamed struct X should the need ever arise.

If that is your "this", then I agree with you 100%. Defining a tagless/nameless struct type, as shown in your example, definitely does not not look like a good idea. I don't like the fact that I have no way to refer to array element type further down in the code.

To be pedantic, in a pinch it would still possible to refer to the array element type using `decltype` in C++ and `typeof` in the upcoming C23. But I'd personally just give that struct type a tag.

Yes that's all I'm saying here, if designing a new language that had the ability to do something akin to C's typedef, it would be wise to disallow that kind of use.

[DiTBho]

Defining a type that is actually an array is.. oof.

Yup

the only good one, the most close one, is this

Code: [Select]

typedef char_t ans_test_body_t[8];
typedef ans_test_body_t ans_test_t[2];

ans_test_t ans_test={ "failure", "success"};

...

result = do_test(i0);
printf("test-%04lu: %s\n", i0, ans_test[result);
(my-c)

[Sherlock Holmes]

Here's the Ada question, how does one write this in Ada

Code: [Select]

    struct Info{
        char name[30];
        int age;
        struct address{
            char area_name[39];
            int house_no;
            char district[39];
        };
    };


And bam, that's again a particular case which was absolutely not obvious in your original question. A record inside a record? No problem. But what you actually meant was: an anonymous record. How are we supposed to guess?

Anonymous struct/union members in C have been a GCC extension for a long time, but are non-standard. The standard way was to give the member a name. Just like with other languages.
So instead of something like 'info.house_no' directly, you would have to give the address member a name (eg, 'address'), and access it as 'info.address.house_no'. Same in Ada. Ada has variant records (Pascal had them too IIRC) though, and you can get the somewhat equivalent of "anonymous union members inside a struct" in C.

Anonymous stuct/union members can be elegant in some cases, but one should not abuse them IMO.
And I think - but I'm not 100% sure - they have made their way in the C standard in C23. But that has to be checked, surely. (Was it in C11 even?)

Very well, how does Ada do this then, I did not mean to make then annonymous.

Code: [Select]

struct info {
char name[30];
int age;
struct address {
char area_name[39];
int house_no;
char district[39];
} Address;
} Info;

I can refer to "house_no" so long as I qualify the reference to it with Info.Address. But how can one do that in Ada, nest structure declarations in that way? That's the question I'm struggling to find an answer too...

[newbrain]

Anonymous struct/union members in C have been a GCC extension for a long time, but are non-standard. The standard way was to give the member a name. Just like with other languages.
[...]
And I think - but I'm not 100% sure - they have made their way in the C standard in C23. But that has to be checked, surely. (Was it in C11 even?)

They are in fact in C11, "6.7.2.1 Structure and union specifiers", §13:

An unnamed member whose type specifier is a structure specifier with no tag is called an
anonymous structure; an unnamed member whose type specifier is a union specifier with
no tag is called an anonymous union. The members of an anonymous structure or union
are considered to be members of the containing structure or union. This applies
recursively if the containing structure or union is also anonymous.

[Sherlock Holmes]

The Ada question is interesting to me because I do think this kind of array definition is fine:

Code: [Select]

struct info {
char name[30];
int age;
struct address {
char area_name[39];
int house_no;
char district[39];
} Address[4];
} Info;

This is a struct with a storage layout and if that storage layout contains four contiguous 'Address' elements then that's fine, these aren't type definitions.

I'm curious as to how Ada expresses this or if it forces us to define types and construct the structure in terms of those types, like that's the only way to do it...

[Sherlock Holmes]

Anonymous struct/union members in C have been a GCC extension for a long time, but are non-standard. The standard way was to give the member a name. Just like with other languages.
[...]
And I think - but I'm not 100% sure - they have made their way in the C standard in C23. But that has to be checked, surely. (Was it in C11 even?)

They are in fact in C11, "6.7.2.1 Structure and union specifiers", §13:

An unnamed member whose type specifier is a structure specifier with no tag is called an
anonymous structure; an unnamed member whose type specifier is a union specifier with
no tag is called an anonymous union. The members of an anonymous structure or union
are considered to be members of the containing structure or union. This applies
recursively if the containing structure or union is also anonymous.

What's rather bothersome about C is the way we have a name in two parts of the declaration:

Code: [Select]

struct info {
char name[30];
int age;
struct address {
char area_name[39];
int house_no;
char district[39];
} Address;
} Info;

Here we see a thing called 'address' and another thing called 'Address', it's a very odd syntax indeed.

[cfbsoftware]

Code: [Select]

    struct Info{
        char name[30];
        int age;
        struct address{
            char area_name[39];
            int house_no;
            char district[39];
        };
    };

I can refer to "house_no" so long as I qualify the reference to it with Info.Address. But how can one do that in Ada, nest structure declarations in that way? That's the question I'm struggling to find an answer too...

Oberon is similar to Ada for these types of declarations. In Oberon this is written as:

Code: [Select]

TYPE
  Info = RECORD
    name: ARRAY 30 OF CHAR;
    age: INTEGER;
    address:
      RECORD
        areaName: ARRAY 39 OF CHAR;
        houseNo: INTEGER;
        district: ARRAY 39 OF CHAR;
      END;
    END;
   
However, I would be more likely (depending on the exact requirements) to write this as:

Code: [Select]

TYPE
  Name = ARRAY 30 OF CHAR;
  Location = ARRAY 39 OF CHAR;

  Address = RECORD
    houseNo: INTEGER;
    areaName, district: Location;
  END;
   
  Person = RECORD
    name: Name;
    age: INTEGER;
    address: Address;
  END;
In Oberon entire records can be assigned so, given these declarations you could write:

Code: [Select]

VAR
  twin1, twin2: Person;
 
...
...
  twin2 := twin1;
  twin1.name := "John Smith";
  twin2.name := "Jane Smith";
...
...


[TheCalligrapher]

They are in fact in C11, "6.7.2.1 Structure and union specifiers", §13:

An unnamed member whose type specifier is a structure specifier with no tag is called an
anonymous structure; an unnamed member whose type specifier is a union specifier with
no tag is called an anonymous union. The members of an anonymous structure or union
are considered to be members of the containing structure or union. This applies
recursively if the containing structure or union is also anonymous.

They are. But they still require the nested struct declaration to be tagless. The original OP's declaration is invalid in C, regardless of how you slice it.

[TheCalligrapher]

Here we see a thing called 'address' and another thing called 'Address', it's a very odd syntax indeed.

It's a type name (a tag) and a variable name. There's nothing unusual in the fact that you have to name the two separately. In any programming language, I'd say. Types are types, variables are variables.

The only thing that might be seen as odd here is the fact that you decided to lump them up into a single declaration. But that's entirely of your doing. You didn't have to do it that way.

[SiliconWizard]

Here we see a thing called 'address' and another thing called 'Address', it's a very odd syntax indeed.

It's a type name (a tag) and a variable name. There's nothing unusual in the fact that you have to name the two separately. In any programming language, I'd say. Types are types, variables are variables.

The only thing that might be seen as odd here is the fact that you decided to lump them up into a single declaration. But that's entirely of your doing. You didn't have to do it that way.

Yes. Actually, I'm not sure I fully understand the consistency of everything here.
The OP seems to say he doesn't want to allow declarations of hierarchical types directly, yet shows an example of a nested hierarchical declaration. The consistency eludes me.

[gf]

Here we see a thing called 'address' and another thing called 'Address', it's a very odd syntax indeed.

It's a type name (a tag) and a variable name. There's nothing unusual in the fact that you have to name the two separately. In any programming language, I'd say. Types are types, variables are variables.

The only thing that might be seen as odd here is the fact that you decided to lump them up into a single declaration. But that's entirely of your doing. You didn't have to do it that way.

What's also special in C is the differentiation between struct/union names (which always need to be prefixed with 'struct' or 'union') and type names (declared via typedef). In C++, OTOH, struct S {...}; also declares a type name 'S' which can be referenced directly, without 'struct' prefix.

[Sherlock Holmes]

Code: [Select]

    struct Info{
        char name[30];
        int age;
        struct address{
            char area_name[39];
            int house_no;
            char district[39];
        };
    };

I can refer to "house_no" so long as I qualify the reference to it with Info.Address. But how can one do that in Ada, nest structure declarations in that way? That's the question I'm struggling to find an answer too...

Oberon is similar to Ada for these types of declarations. In Oberon this is written as:

Code: [Select]

TYPE
  Info = RECORD
    name: ARRAY 30 OF CHAR;
    age: INTEGER;
    address:
      RECORD
        areaName: ARRAY 39 OF CHAR;
        houseNo: INTEGER;
        district: ARRAY 39 OF CHAR;
      END;
    END;
   
However, I would be more likely (depending on the exact requirements) to write this as:

Code: [Select]

TYPE
  Name = ARRAY 30 OF CHAR;
  Location = ARRAY 39 OF CHAR;

  Address = RECORD
    houseNo: INTEGER;
    areaName, district: Location;
  END;
   
  Person = RECORD
    name: Name;
    age: INTEGER;
    address: Address;
  END;
In Oberon entire records can be assigned so, given these declarations you could write:

Code: [Select]

VAR
  twin1, twin2: Person;
 
...
...
  twin2 := twin1;
  twin1.name := "John Smith";
  twin2.name := "Jane Smith";
...
...


Thank you this is most interesting.

Here is the current syntax for "defining a new type" (or rather "alias" might be the better term).

Code: [Select]

      type outer             structure; 
         cpu_id              bin(31);
         inner               structure;
            cpu_mode         bin(31);
            cpu_rev          bin(15);
            large as         Header;
            flag_table       structure; 
               root          pointer;
               depth         fixed bin(15);
               structure     structure;
                  goofy      pointer;
               end;
            end;   
            label            string(64);
         end;
         owner               string(64);
         speed(100) as       baud_rates;
         counter             string(32);
      end;

This works, and it and several complex variants now parse without issue and build the expected parse tree.

I can see that making say 'flag_table' an array, is entirely legitimate, it is describing the layout of some structured storage, so an array of members be they scalar fields or structures is entirely sensible.

The conceptual concern I have is that 'outer' (the main structure itself) is not itself a structure but a 'type' name and so allowing that to be subscripted is a bad idea for the reasons I mention above.

So its just niggling me that the type is defined as "outer structure" and embedded struct instance like "flag_table structure" use the same notation, but then again the former is prefixed by "type".

Furthermore I am inclined to disallow the declaration of structure instances like this, to only allow a "type" or "alias" to be defined this way and then one must use that alias to declare instances. But I don't want to impose that rule when inserting sub structures inside some larger structure, so I don't want to force the developer to define a "type" for an embedded structure if they don't want to, only for the outermost structure.

So I'm trying to rationalize all this in a way that is completely free of contrived syntactic rules...

By the way the "name as othername" is the way we declare "name" as being of user defined type "othername".

[Sherlock Holmes]

They are in fact in C11, "6.7.2.1 Structure and union specifiers", §13:

An unnamed member whose type specifier is a structure specifier with no tag is called an
anonymous structure; an unnamed member whose type specifier is a union specifier with
no tag is called an anonymous union. The members of an anonymous structure or union
are considered to be members of the containing structure or union. This applies
recursively if the containing structure or union is also anonymous.

They are. But they still require the nested struct declaration to be tagless. The original OP's declaration is invalid in C, regardless of how you slice it.

This is valid C:

Code: [Select]

typedef struct {
    int age;
    int height;
} Person[3];

See this slightly later post for proof of that.

https://www.eevblog.com/forum/programming/c-and-its-many-oddities/msg4654957/#msg4654957

[Sherlock Holmes]

Here we see a thing called 'address' and another thing called 'Address', it's a very odd syntax indeed.

It's a type name (a tag) and a variable name. There's nothing unusual in the fact that you have to name the two separately. In any programming language, I'd say. Types are types, variables are variables.

The only thing that might be seen as odd here is the fact that you decided to lump them up into a single declaration. But that's entirely of your doing. You didn't have to do it that way.

Oh I understand it, it's just a very contrived syntax, what I mean it could have been simpler.

[Sherlock Holmes]

Here we see a thing called 'address' and another thing called 'Address', it's a very odd syntax indeed.

It's a type name (a tag) and a variable name. There's nothing unusual in the fact that you have to name the two separately. In any programming language, I'd say. Types are types, variables are variables.

The only thing that might be seen as odd here is the fact that you decided to lump them up into a single declaration. But that's entirely of your doing. You didn't have to do it that way.

Yes. Actually, I'm not sure I fully understand the consistency of everything here.
The OP seems to say he doesn't want to allow declarations of hierarchical types directly, yet shows an example of a nested hierarchical declaration. The consistency eludes me.

Not at all, where did I say I "don't want to allow declarations of hierarchical types directly"? which post are you interpreting that way?

All I've said is that in a language that lets you define an alias/typedef for something else, there should be no scope for that alias/typedef to inherently be an array. The reasons are expounded upon above.

[TheCalligrapher]

They are. But they still require the nested struct declaration to be tagless. The original OP's declaration is invalid in C, regardless of how you slice it.

This is valid C:

Code: [Select]

typedef struct {
    int age;
    int height;
} Person[3];

See this slightly later post for proof of that.

Yes, this is valid. I'm not arguing with that.

I was referring to another "original" declaration: the one in the sub-discussion about anonymous structs. This one:

Code: [Select]

    struct Info{
        char name[30];
        int age;
        struct address{
            char area_name[39];
            int house_no;
            char district[39];
        };
    };
This is not valid C.

[Sherlock Holmes]

Well regarding this whole subject of structures and typedefs, I've settled on IPL having a slightly simpler approach.

Basically one cannot declare a structure using structure declaration syntax. That structure declaration syntax can ONLY be used to define a "type", e.g.

Code: [Select]

      type flag_table         structure; 
            root              pointer;
            depth             fixed bin(15);
               subunit        structure;
                  goofy       pointer;
               end;
            end;   

To declare a structure instance, one must use and can only use, the type's name:

Code: [Select]

dcl my_data as flag_table;

The above could also be:

Code: [Select]

      type Subunit structure;
           goofy pointer;
      end;

      type flag_table structure; 
            root          pointer;
            depth         fixed bin(15);
            subunit  as Subunit;
      end;   

Same goes for "enum" one must define an enum using "type" and then instances of it using that type's name.

I see nothing useful in being able to declare a struct instance explicitly with structure syntax, when we can define types using structure syntax and declare instances of said type, nothing useful about that IMHO.

This might seem like much ado about nothing, but it's part of the endeavor to reduce language "noise", eliminate redundant concepts and code structures.

[Sherlock Holmes]

Code: [Select]

    struct Info{
        char name[30];
        int age;
        struct address{
            char area_name[39];
            int house_no;
            char district[39];
        };
    };

I can refer to "house_no" so long as I qualify the reference to it with Info.Address. But how can one do that in Ada, nest structure declarations in that way? That's the question I'm struggling to find an answer too...

Oberon is similar to Ada for these types of declarations. In Oberon this is written as:

Code: [Select]

TYPE
  Info = RECORD
    name: ARRAY 30 OF CHAR;
    age: INTEGER;
    address:
      RECORD
        areaName: ARRAY 39 OF CHAR;
        houseNo: INTEGER;
        district: ARRAY 39 OF CHAR;
      END;
    END;
   
However, I would be more likely (depending on the exact requirements) to write this as:

Code: [Select]

TYPE
  Name = ARRAY 30 OF CHAR;
  Location = ARRAY 39 OF CHAR;

  Address = RECORD
    houseNo: INTEGER;
    areaName, district: Location;
  END;
   
  Person = RECORD
    name: Name;
    age: INTEGER;
    address: Address;
  END;
In Oberon entire records can be assigned so, given these declarations you could write:

Code: [Select]

VAR
  twin1, twin2: Person;
 
...
...
  twin2 := twin1;
  twin1.name := "John Smith";
  twin2.name := "Jane Smith";
...
...


In your second example of a 'TYPE' it seems that that type has no name, whereas the first one has a name of 'Info', so these are alternative ways of declaring a structure instance?

Yes structure to structure assignments are important, C has that too. In PL/I there was an assignment option of 'by name' that allowed one type of structure to be assigned from another type but only where the member names match.

This might be something I want to expand upon, but I don't know if it is ultimately helpful, the 'by name' seems to have its roots in older mainframe COBOL days where data was always processed by consuming files, sequences or structured records. Some of the strictures I saw used in PL/I in the 80s were sometimes very big indeed, and might have even been designed with 'by name' in mind.

The problem I have with 'by name' is that I can imagine scenarios where someone innocently adds some new member to some structure or renames some member, and all of a sudden some 'by name' assignment start to do more than it used to, in a way that was unexpected by the person making the change.

Perhaps a richer syntax might work:

Code: [Select]

record = master_record by name (address, phone_numbers);

This way the members impacted by the assignment are clearly visible. But that more or less boils down to:

Code: [Select]

record.address = master_record.address;
record.phone_numbers = master_record.phone_numbers;

So I was never a fan of 'by name'.

[Sherlock Holmes]

Actually just perusing the ANSI X3.74-1987 standard, there is no 'by name' option, it was basically part of old "full PL/I".

[cfbsoftware]

In your second example of a 'TYPE' it seems that that type has no name, whereas the first one has a name of 'Info', so these are alternative ways of declaring a structure instance?

The type in my second example does have a name. I renamed it to Person from Info - just a personal preference