You can repeat it until you're keyboard is dust, but the number of repetitions won't change the fact that you have misunderstood my proposal. Unions aren't complicated and I understand how they work (and structs as well).

Yes, of course. A union is large enough to store its largest member but can only hold one member at a time. If the union consisted of a long int and a float, the same would be true, since their base address would be the same. I understand this. It looks like you do too. This suggests to me that the misunderstanding is not at the C language level, but higher up.

Look at your code (in post #4) where you first suggested the arrangement where both structs and the union include the type int as their first member.

Are you suggesting that mycs.type and myds.type occupy the same memory location? Obviously not. They are different instances of different types. My point regarding pointlessly increasing storage is that neither of those instances needs a type member. Any code that deals with them directly knows what they are.

The only code that needs to discover the type is the code handling a union. Wrap the union in a struct, and only in the struct that wraps the union do you have a member which serves as a type tag. If we were working with thousands of instances of CS/DS or mystr1/mystr2, and only needed one instance of a union to pass to/from functions, then with your approach there would be thousands of pointless type ints consuming storage when only one would be needed.

This statement also suggests that you completely misunderstood my proposal, because tagged unions are conceptually simple and extremely common. Not only do they work well, they are a natural way to express anything which can take on one of several aspects.

Browsing OpenBSD online cvsweb: nawk has a tagged union at the core of the finite automaton which implements its regular expression engine. find uses a tagged union for the core of its planner (which implements the boolean expression of command line primaries). I saw two tagged unions in a sed header, one for sed commands and one for addresses.

To not make an already long post longer than it needs to be, I will only show the simplest case, the tagged union representing sed line addresses:

Code:

/*
 * Format of an address
 */
struct s_addr {
        enum e_atype type;                      /* Address type */
        union {
                u_long l;                       /* Line number */
                regex_t *r;                     /* Regular expression */
        } u;
};

The type member tags the union and informs any code that accesses the union which type of address it contains. Neither address data type (u_long and regex_t) needs to carry around its type. For example, any code that works with line number addresses knows that it's dealing with u_long.

Have you actually never seen this type of data structure before, where one of the members is a union and another is the type of the union's current/active member?

Replace the union members in that sed example, u_long and regex_t, with CS and DS and you have exactly what I suggested when I said to leave the original structs unmodified and use a tagged union.

If after reading this post you still believe that I don't understand unions, and if you feel the need to educate me, please take a moment and a breath to consider that it may be you that is missing something, probably not at the C language level, but somewhere else.

Regards,
Alister