tags:

views:

2849

answers:

8

What is the sizeof the union in C/C++? Is it the sizeof the largest datatype inside it? If so, how does the compiler calculate how to move the stack pointer if one of the smaller datatype of the union is active?

+28  A: 

A union always takes up as much space as the largest member. It doesn't matter what is currently in use.

union {
  short x;
  int y;
  long long z;
}

An instance of the above union will always take at least a long long for storage.

Side note: As noted by Stefano, the actual space any type (union, struct, class) will take does depend on other issues such as alignment by the compiler. I didn't go through this for simplicity as I just wanted to tell that a union takes the biggest item into account. It's important to know that the actual size does depend on alignment.

Mehrdad Afshari
One place where sizeof might return something larger is when a long double is being used. A long double is 10-bytes but Intel recommends aligning at 16-bytes.
dreamlax
long double is ... well, depends on the compiler. I *think* PowerPC compilers use 128bit long doubles
Mehrdad Afshari
Yeah whoops I meant to say a long double on x86.
dreamlax
+7  A: 

There is no notion of active datatype for a union. You are free to read and write any 'member' of the union: this is up to you to interpret what you get.

Therefore, the sizeof a union is always the sizeof its largest datatype.

mouviciel
+3  A: 

The size will be at least that of the largest composing type. There is no concept of an "active" type.

anon
+2  A: 

You should really look at a union as a container for the largest datatype inside it combined with a shortcut for a cast. When you use one of the smaller members, the unused space is still there, but it simply stays unused.

You often see this used in combination with ioctl() calls under in Unix, all ioctl() calls will pass the same struct, which contains a union of all possible responses. E.g. this example comes from /usr/include/linux/if.h and this struct is used in ioctl()'s for configuring/querying the state of an ethernet interface, the request parameters defines which part of the union is actually in use:

struct ifreq 
{
#define IFHWADDRLEN 6
    union
    {
     char ifrn_name[IFNAMSIZ];  /* if name, e.g. "en0" */
    } ifr_ifrn;

    union {
     struct sockaddr ifru_addr;
     struct sockaddr ifru_dstaddr;
     struct sockaddr ifru_broadaddr;
     struct sockaddr ifru_netmask;
     struct  sockaddr ifru_hwaddr;
     short ifru_flags;
     int ifru_ivalue;
     int ifru_mtu;
     struct  ifmap ifru_map;
     char ifru_slave[IFNAMSIZ]; /* Just fits the size */
     char ifru_newname[IFNAMSIZ];
     void * ifru_data;
     struct if_settings ifru_settings;
    } ifr_ifru;
};
amo-ej1
A: 
  1. The size of the largest member.

  2. This is why unions usually make sense inside a struct that has a flag that indicates which is the "active" member.

Example:

struct ONE_OF_MANY {
    enum FLAG { FLAG_SHORT, FLAG_INT, FLAG_LONG_LONG } flag;
    union { short x; int y; long long z; };
};
Eduardo León
Not true. A common use is to access smaller parts of a larger type. Example: union U { int i; char c[4]; }; can be used to give (implementation specific) access to bytes of a 4-byte integer.
anon
Oh, true... I haven't noticed that possibility. I have always accessed parts of a larger type using byte shifts and that kind of things.
Eduardo León
+6  A: 

It depends on the compiler, and on the options.

int main() {
  union {
    char all[13];
    int foo;
  } record;

printf("%d\n",sizeof(record.all));
printf("%d\n",sizeof(record.foo));
printf("%d\n",sizeof(record));

}

This outputs:

13 4 16

If I remember correctly, it depends on the alignment that the compiler puts into the allocated space. So, unless you use some special option, the compiler will put padding into your union space.

edit: with gcc you need to use a pragma directive

int main() {
#pragma pack(push, 1)
      union {
           char all[13];
           int foo;
      } record;
#pragma pack(pop)

      printf("%d\n",sizeof(record.all));
      printf("%d\n",sizeof(record.foo));
      printf("%d\n",sizeof(record));

}

this outputs

13 4 13

You can also see it from the disassemble (removed some printf, for clarity)

  0x00001fd2 <main+0>:    push   %ebp             |  0x00001fd2 <main+0>:    push   %ebp
  0x00001fd3 <main+1>:    mov    %esp,%ebp        |  0x00001fd3 <main+1>:    mov    %esp,%ebp
  0x00001fd5 <main+3>:    push   %ebx             |  0x00001fd5 <main+3>:    push   %ebx
  0x00001fd6 <main+4>:    sub    $0x24,%esp       |  0x00001fd6 <main+4>:    sub    $0x24,%esp
  0x00001fd9 <main+7>:    call   0x1fde <main+12> |  0x00001fd9 <main+7>:    call   0x1fde <main+12>
  0x00001fde <main+12>:   pop    %ebx             |  0x00001fde <main+12>:   pop    %ebx
  0x00001fdf <main+13>:   movl   $0xd,0x4(%esp)   |  0x00001fdf <main+13>:   movl   $0x10,0x4(%esp)                                         
  0x00001fe7 <main+21>:   lea    0x1d(%ebx),%eax  |  0x00001fe7 <main+21>:   lea    0x1d(%ebx),%eax
  0x00001fed <main+27>:   mov    %eax,(%esp)      |  0x00001fed <main+27>:   mov    %eax,(%esp)
  0x00001ff0 <main+30>:   call  0x3005 <printf>   |  0x00001ff0 <main+30>:   call   0x3005 <printf>
  0x00001ff5 <main+35>:   add    $0x24,%esp       |  0x00001ff5 <main+35>:   add    $0x24,%esp
  0x00001ff8 <main+38>:   pop    %ebx             |  0x00001ff8 <main+38>:   pop    %ebx
  0x00001ff9 <main+39>:   leave                   |  0x00001ff9 <main+39>:   leave
  0x00001ffa <main+40>:   ret                     |  0x00001ffa <main+40>:   ret

Where the only difference is in main+13, where the compiler allocates on the stack 0xd instead of 0x10

Stefano Borini
Thank you - saves me having to assemble this answer!
Jonathan Leffler
Yes, I suppose we should all have said "At _least_ as big as the largest contained type".
anon
@Neil: compiler alignment is a totally different issue. It happens in structs too and also depends on the place you put the union in the struct. While this is certainly true, I think it just complicates the answer to *this* question. btw, I was careful to align my sample union to 8byte boundary :-p
Mehrdad Afshari
+12  A: 

The Standard answers all questions in section 9.5:

In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. [Note: one special guarantee is made in order to simplify the use of unions: If a POD-union contains several POD-structs that share a common initial sequence (9.2), and if an object of this POD-union type contains one of the POD-structs, it is permitted to inspect the common initial sequence of any of POD-struct members; see 9.2. ] The size of a union is sufficient to contain the largest of its data members. Each data member is allocated as if it were the sole member of a struct.

That means each member share the same memory region. There is at most one member active, but you can't find out which one. You will have to store that information about the currently active member yourself somewhere else. Storing such a flag in addition to the union (for example having a struct with an integer as the type-flag and an union as the data-store) will give you a so called "discriminated union": An union which knows what type in it is currently the "active one".

One common use is in lexers, where you can have different tokens, but depending on the token, you have different informations to store (putting line into each struct to show what a common initial sequence is):

struct tokeni {
    int token; /* type tag */
    union {
        struct { int line; } noVal;
        struct { int line; int val; } intVal;
        struct { int line; struct string val; } stringVal;
    } data;
};

The Standard allows you to access line of each member, because that's the common initial sequence of each one.

There exist compiler extensions that allow accessing all members disregarding which one currently has its value stored. That allows efficient reinterpretation of stored bits with different types among each of the members. For example, the following may be used to dissect a float variable into 2 unsigned shorts:

union float_cast { unsigned short s[2]; float f; };

That can come quite handy when writing low-level code. If the compiler does not support that extension, but you do it anyway, you write code whose results are not defined. So be certain your compiler has support for it if you use that trick.

Johannes Schaub - litb
A horrible example of bad Standard language IMHO - in fact the whole section on unions seems a bit skimped. Why introduce the concept of "active" at all?
anon
seems reasonable to me. reinterpreting the underlying bits of an object according to a different type may be dangerous and can yield trap representations for the other type (you could for example silently create a signalling NaNs or something, or a trapping pointer value).
Johannes Schaub - litb
GCC at least explicitly supports cross reading of union members. and if the members are somehow related according to 3.10/15 or are layout-compatible, i'm pretty sure you can still read the other member even tho it's not the "active" one.
Johannes Schaub - litb
It's the "active" bit that gets me. if 9.5\1 were to start with "the value of at most" then there would be no need to introduce this nebulous concept of "active". But this should (if anywhere) be on comp.lang.c++.std, and not in a godawful SO comment box! So I'm signing off on this topic.
anon
haha, alright. start off a thread there and let's have fun :p
Johannes Schaub - litb
A: 

hi friends , now question is how calculate the sizeof union ->

include

union { int a; char b[13]; }u; int main() { printf("%d",sizeof(u));

return 0;

}

her int a value is = 4 and char b[13] value is =13 reminder = 13%4;

reminder is =1; then reminder+3=4;complete the 4byte the value 3 value is add with 13+3=16 the sizeof union is ====== 16

govind