When would anyone use a union? Is it a remnant from the C-only days?

Question

I have learned but don't really get unions. Every C or C++ text I go through introduces them (sometimes in passing), but they tend to give very few practical examples of why or where to use them. When would unions be useful in a modern (or even legacy) case? My only two guesses would be programming microprocessors when you have very limited space to work with, or when you're developing an API (or something similar) and you want to force the end user to have only one instance of several objects/types at one time. Are these two guesses even close to right?

Vickyvico

C/C++ is not a language. Unions are moderately useful in C and largely useless in C++. It would be correct to say that in C++ they're a "remnant from C++ being based on C", but not to say they're "a remnant from the C only days" as if C++ supercedes C. – Lorrianelorrie

Can you elaborate on what c++'s substitute for unions is, or why they are useless in c++? – Vickyvico

C++'s substitute for unions is classes & inheritance - unions in C are almost exclusively used for type-safe polymorphism. Something classes are much better at. (See vz0's answer for C-style polymorphism) – Airdry

C++'s substitute for unions is boost::variant – Georama

@R..: union are still moderately useful in C++. See answers below. – Schizophrenia

Unions can be extraordinarily valuable in the guts of an operating system, or in, eg, a package that assembles/disassembles sound files. In such contexts they are used multiple different ways -- data/endian conversion, low-level polymorphism, et al. Yes, there are other solutions to the same problem (mainly casting between pointer types), but unions are often cleaner and better self-documenting. – Inigo

@Airdry classes and inheritance do not, by and large, supplant much of the uses for unions; they are much less flexible than the visitor pattern. A lot of times, more than one return type is acceptable or useful, or argument/returns are optional, etc etc. Unions are a basic building block for optimal implementation of these details. – Handily

Answer 1

Unions are usually used with the company of a discriminator: a variable indicating which of the fields of the union is valid. For example, let's say you want to create your own Variant type:

struct my_variant_t {
    int type;
    union {
        char char_value;
        short short_value;
        int int_value;
        long long_value;
        float float_value;
        double double_value;
        void* ptr_value;
    };
};

Then you would use it such as:

/* construct a new float variant instance */
void init_float(struct my_variant_t* v, float initial_value) {
    v->type = VAR_FLOAT;
    v->float_value = initial_value;
}

/* Increments the value of the variant by the given int */
void inc_variant_by_int(struct my_variant_t* v, int n) {
    switch (v->type) {
    case VAR_FLOAT:
        v->float_value += n;
        break;

    case VAR_INT:
        v->int_value += n;
        break;
    ...
    }
}

This is actually a pretty common idiom, specially on Visual Basic internals.

For a real example see SDL's SDL_Event union. (actual source code here). There is a type field at the top of the union, and the same field is repeated on every SDL_*Event struct. Then, to handle the correct event you need to check the value of the type field.

The benefits are simple: there is one single data type to handle all event types without using unnecessary memory.

Giraudoux

Great! In that case, I'm now wondering why the Sdl function wasn't just implemented as a class hierarchy. Is that to make it C compatible and not just C++? – Vickyvico

@Vickyvico C++ classes can not be used from a C program, but C structs/unions can be easily accesed from C++ using an 'extern "C"' block. – Giraudoux

This variant pattern is also often used for programming language interpreters, e.g. the definition of struct object in github.com/petermichaux/bootstrap-scheme/blob/v0.21/scheme.c – Petromilli

Awesome explanation. I always knew what unions were, but never saw a real-world reason of why anyone would be crazy enough to use them :) Thanks for the example. – Lipp

@Stargazer712, Google's codesearch: google.com/… – Bestiary

Answer 2

I find C++ unions pretty cool. It seems that people usually only think of the use case where one wants to change the value of a union instance "in place" (which, it seems, serves only to save memory or perform doubtful conversions).

In fact, unions can be of great power as a software engineering tool, even when you never change the value of any union instance.

Use case 1: the chameleon

With unions, you can regroup a number of arbitrary classes under one denomination, which isn't without similarities with the case of a base class and its derived classes. What changes, however, is what you can and can't do with a given union instance:

struct Batman;
struct BaseballBat;

union Bat
{
    Batman brucewayne;
    BaseballBat club;
};

ReturnType1 f(void)
{
    BaseballBat bb = {/* */};
    Bat b;
    b.club = bb;
    // do something with b.club
}

ReturnType2 g(Bat& b)
{
    // do something with b, but how do we know what's inside?
}

Bat returnsBat(void);
ReturnType3 h(void)
{
    Bat b = returnsBat();
    // do something with b, but how do we know what's inside?
}

It appears that the programmer has to be certain of the type of the content of a given union instance when he wants to use it. It is the case in function f above. However, if a function were to receive a union instance as a passed argument, as is the case with g above, then it wouldn't know what to do with it. The same applies to functions returning a union instance, see h: how does the caller know what's inside?

If a union instance never gets passed as an argument or as a return value, then it's bound to have a very monotonous life, with spikes of excitement when the programmer chooses to change its content:

Batman bm = {/* */};
Baseball bb = {/* */};
Bat b;
b.brucewayne = bm;
// stuff
b.club = bb;

And that's the most (un)popular use case of unions. Another use case is when a union instance comes along with something that tells you its type.

Use case 2: "Nice to meet you, I'm object, from Class"

Suppose a programmer elected to always pair up a union instance with a type descriptor (I'll leave it to the reader's discretion to imagine an implementation for one such object). This defeats the purpose of the union itself if what the programmer wants is to save memory and that the size of the type descriptor is not negligible with respect to that of the union. But let's suppose that it's crucial that the union instance could be passed as an argument or as a return value with the callee or caller not knowing what's inside.

Then the programmer has to write a switch control flow statement to tell Bruce Wayne apart from a wooden stick, or something equivalent. It's not too bad when there are only two types of contents in the union but obviously, the union doesn't scale anymore.

Use case 3:

As the authors of a recommendation for the ISO C++ Standard put it back in 2008,

Many important problem domains require either large numbers of objects or limited memory resources. In these situations conserving space is very important, and a union is often a perfect way to do that. In fact, a common use case is the situation where a union never changes its active member during its lifetime. It can be constructed, copied, and destructed as if it were a struct containing only one member. A typical application of this would be to create a heterogeneous collection of unrelated types which are not dynamically allocated (perhaps they are in-place constructed in a map, or members of an array).

And now, an example, with a UML class diagram:

The situation in plain English: an object of class A can have objects of any class among B1, ..., Bn, and at most one of each type, with n being a pretty big number, say at least 10.

We don't want to add fields (data members) to A like so:

private:
    B1 b1;
    .
    .
    .
    Bn bn;

because n might vary (we might want to add Bx classes to the mix), and because this would cause a mess with constructors and because A objects would take up a lot of space.

We could use a wacky container of void* pointers to Bx objects with casts to retrieve them, but that's fugly and so C-style... but more importantly that would leave us with the lifetimes of many dynamically allocated objects to manage.

Instead, what can be done is this:

union Bee
{
    B1 b1;
    .
    .
    .
    Bn bn;
};

enum BeesTypes { TYPE_B1, ..., TYPE_BN };

class A
{
private:
    std::unordered_map<int, Bee> data; // C++11, otherwise use std::map

public:
    Bee get(int); // the implementation is obvious: get from the unordered map
};

Then, to get the content of a union instance from data, you use a.get(TYPE_B2).b2 and the likes, where a is a class A instance.

This is all the more powerful since unions are unrestricted in C++11. See the document linked to above or this article for details.

Subtrahend

This was very helpful, and that second article's series was very informative. Thanks. – Convalescence

Answer 3

One example is in the embedded realm, where each bit of a register may mean something different. For example, a union of an 8-bit integer and a structure with 8 separate 1-bit bitfields allows you to either change one bit or the entire byte.

Mesial

This is very common in device drivers as well. A few years back I wrote a lot of code using unions like this for a project. It's not normally recommended, and it can be compiler-specific in some cases, but it works. – Bertilla

I wouldn't call that "not recommended". In the embedded space it's often much cleaner and less error-prone than the alternatives, which usually either involve lots of explicit casts and void*s or masks and shifts. – Teratogenic

heh? Lots of explicit casts? Seems to me simple statements like REG |= MASK and REG &= ~MASK. If that is error prone then put them in a #define SETBITS(reg, mask) and #define CLRBITS(reg, mask). Don't rely on the compiler to get the bits in a certain order (#1490592) – Schizophrenia

Answer 4

Herb Sutter wrote in GOTW about six years ago, with emphasis added:

"But don't think that unions are only a holdover from earlier times. Unions are perhaps most useful for saving space by allowing data to overlap, and this is still desirable in C++ and in today's modern world. For example, some of the most advanced C++ standard library implementations in the world now use just this technique for implementing the "small string optimization," a great optimization alternative that reuses the storage inside a string object itself: for large strings, space inside the string object stores the usual pointer to the dynamically allocated buffer and housekeeping information like the size of the buffer; for small strings, the same space is instead reused to store the string contents directly and completely avoid any dynamic memory allocation. For more about the small string optimization (and other string optimizations and pessimizations in considerable depth), see... ."

And for a less useful example, see the long but inconclusive question gcc, strict-aliasing, and casting through a union.

Isaiasisak

Answer 5

Well, one example use case I can think of is this:

typedef union
{
    struct
    {
        uint8_t a;
        uint8_t b;
        uint8_t c;
        uint8_t d;
    };
    uint32_t x;
} some32bittype;

You can then access the 8-bit separate parts of that 32-bit block of data; however, prepare to potentially be bitten by endianness.

This is just one hypothetical example, but whenever you want to split data in a field into component parts like this, you could use a union.

That said, there is also a method which is endian-safe:

uint32_t x;
uint8_t a = (x & 0xFF000000) >> 24;

For example, since that binary operation will be converted by the compiler to the correct endianness.

Parterre

I think the question is best taken as when should one use unions. You provided an answer of where a union is not the correct tool, which I think should be make more clear in this answer. – Schizophrenia

Answer 6

Some uses for unions:

• Provide a general endianness interface to an unknown external host.
• Manipulate foreign CPU architecture floating point data, such as accepting VAX G_FLOATS from a network link and converting them to IEEE 754 long reals for processing.
• Provide straightforward bit twiddling access to a higher-level type.

union {
      unsigned char   byte_v[16];
      long double     ld_v;
 }

With this declaration, it is simple to display the hex byte values of a long double, change the exponent's sign, determine if it is a denormal value, or implement long double arithmetic for a CPU which does not support it, etc.

• Saving storage space when fields are dependent on certain values:

  class person {  
      string name;  
  
      char gender;   // M = male, F = female, O = other  
      union {  
          date  vasectomized;  // for males  
          int   pregnancies;   // for females  
      } gender_specific_data;
  }
  

• Grep the include files for use with your compiler. You'll find dozens to hundreds of uses of union:

  [wally@zenetfedora ~]$ cd /usr/include
  [wally@zenetfedora include]$ grep -w union *
  a.out.h:  union
  argp.h:   parsing options, getopt is called with the union of all the argp
  bfd.h:  union
  bfd.h:  union
  bfd.h:union internal_auxent;
  bfd.h:  (bfd *, struct bfd_symbol *, int, union internal_auxent *);
  bfd.h:  union {
  bfd.h:  /* The value of the symbol.  This really should be a union of a
  bfd.h:  union
  bfd.h:  union
  bfdlink.h:  /* A union of information depending upon the type.  */
  bfdlink.h:  union
  bfdlink.h:       this field.  This field is present in all of the union element
  bfdlink.h:       the union; this structure is a major space user in the
  bfdlink.h:  union
  bfdlink.h:  union
  curses.h:    union
  db_cxx.h:// 4201: nameless struct/union
  elf.h:  union
  elf.h:  union
  elf.h:  union
  elf.h:  union
  elf.h:typedef union
  _G_config.h:typedef union
  gcrypt.h:  union
  gcrypt.h:    union
  gcrypt.h:    union
  gmp-i386.h:  union {
  ieee754.h:union ieee754_float
  ieee754.h:union ieee754_double
  ieee754.h:union ieee854_long_double
  ifaddrs.h:  union
  jpeglib.h:  union {
  ldap.h: union mod_vals_u {
  ncurses.h:    union
  newt.h:    union {
  obstack.h:  union
  pi-file.h:  union {
  resolv.h:   union {
  signal.h:extern int sigqueue (__pid_t __pid, int __sig, __const union sigval __val)
  stdlib.h:/* Lots of hair to allow traditional BSD use of `union wait'
  stdlib.h:  (__extension__ (((union { __typeof(status) __in; int __i; }) \
  stdlib.h:/* This is the type of the argument to `wait'.  The funky union
  stdlib.h:   causes redeclarations with either `int *' or `union wait *' to be
  stdlib.h:typedef union
  stdlib.h:    union wait *__uptr;
  stdlib.h:  } __WAIT_STATUS __attribute__ ((__transparent_union__));
  thread_db.h:  union
  thread_db.h:  union
  tiffio.h:   union {
  wchar.h:  union
  xf86drm.h:typedef union _drmVBlank {
  

Newsprint

Tsk tsk! Two downvotes and no explanations. That is disappointing. – Newsprint

The example with a person which can hold a man and a woman is very bad design in my eyes. Why not a person base class and a man and woman derived one? Sorry, but manually looking for a variable to determine the stored type in a a data field is bad idea at all. This is handcrafted c code never seen for years. But no downvote, it is only my point of view :-) – Lakshmi

I guess you got the downvotes for the "castrated" or "pregnancies" union. It is a bit sick. – Equivoque

Yeah, I guess it was a dark day. – Newsprint

Answer 7

Unions are useful when dealing with byte-level (low level) data.

One of my recent usage was on IP address modeling which looks like below :

// Composite structure for IP address storage
union
{
    // IPv4 @ 32-bit identifier
    // Padded 12-bytes for IPv6 compatibility
    union
    {
        struct
        {
            unsigned char _reserved[12];
            unsigned char _IpBytes[4];
        } _Raw;

        struct
        {
            unsigned char _reserved[12];
            unsigned char _o1;
            unsigned char _o2;
            unsigned char _o3;
            unsigned char _o4;    
        } _Octet;    
    } _IPv4;

    // IPv6 @ 128-bit identifier
    // Next generation internet addressing
    union
    {
        struct
        {
            unsigned char _IpBytes[16];
        } _Raw;

        struct
        {
            unsigned short _w1;
            unsigned short _w2;
            unsigned short _w3;
            unsigned short _w4;
            unsigned short _w5;
            unsigned short _w6;
            unsigned short _w7;
            unsigned short _w8;   
        } _Word;
    } _IPv6;
} _IP;

Unoccupied

Keep in mind though, that accessing raw stuff like that isn't standard, and might not work as expected with all compilers. – Whaling

Also, it's very common to see this used in a way that doesn't guarantee the alignment, which is undefined behavior. – Georama

Answer 8

Unions provide polymorphism in C.

Shackleford

I thought void* did that ^^ – Ransom

@Ransom Polymorphism is using the same interface to manipulate multiple types; void* has no interface. – Handily

In C, polymorphism is commonly implemented through opaque types and/or function pointers. I have no idea how or why you would use an union to achieve that. It sounds like a genuinely bad idea. – Discretion

Answer 9

An example when I've used a union:

class Vector
{
        union 
        {
            double _coord[3];
            struct 
            {
                double _x;
                double _y; 
                double _z;
            };

        };
...
}

this allows me to access my data as an array or the elements.

I've used a union to have the different terms point to the same value. In image processing, whether I was working on columns or width or the size in the X direction, it can become confusing. To alleve this problem, I use a union so I know which descriptions go together.

   union {   // dimension from left to right   // union for the left to right dimension
        uint32_t            m_width;
        uint32_t            m_sizeX;
        uint32_t            m_columns;
    };

    union {   // dimension from top to bottom   // union for the top to bottom dimension
        uint32_t            m_height;
        uint32_t            m_sizeY;
        uint32_t            m_rows;
    };

Euhemerus

Note, that although this solution works on most of observable platforms, setting values to _x, _y, _z and accessing _coord is an undefined behavior. The main purpose of unions is space preserving. You must access exactly the same union element that you previously set. – Grams

this is how i use it too, althrough I use a std::array forr coords, and some static_asserts – Recognizee

This code violates the strict aliasing rules and must not be recommended. – Formfitting

Is there perhaps a way to improve the union such that it would be reliable to do this? – Convalescence

Answer 10

The union keyword, while still used in C++03¹, is mostly a remnant of the C days. The most glaring issue is that it only works with POD¹.

The idea of the union, however, is still present, and indeed the Boost libraries feature a union-like class:

boost::variant<std::string, Foo, Bar>

Which has most of the benefits of the union (if not all) and adds:

• ability to correctly use non-POD types
• static type safety

In practice, it has been demonstrated that it was equivalent to a combination of union + enum, and benchmarked that it was as fast (while boost::any is more of the realm of dynamic_cast, since it uses RTTI).

¹Unions were upgraded in C++11 (unrestricted unions), and can now contain objects with destructors, although the user has to invoke the destructor manually (on the currently active union member). It's still much easier to use variants.

Hydrogenize

This is no longer true in more recent versions of c++. See jrsala's answer, for instance. – Convalescence

@Andrew: I updated the answer to mention that C++11, with unrestricted unions, allowed types with destructors to be stored in union. I still stand by my stance that you really are much better off using tagged unions such as boost::variant than to try to use unions on their own. There's way too much undefined behavior surrounding unions that your chances of getting it right are abysmal. – Hydrogenize

Answer 11

A brilliant usage of union is memory alignment, which I found in the PCL(Point Cloud Library) source code. The single data structure in the API can target two architectures: CPU with SSE support as well as the CPU without SSE support. For eg: the data structure for PointXYZ is

typedef union
{
  float data[4];
  struct
  {
    float x;
    float y;
    float z;
  };
} PointXYZ;

The 3 floats are padded with an additional float for SSE alignment. So for

PointXYZ point;

The user can either access point.data[0] or point.x (depending on the SSE support) for accessing say, the x coordinate. More similar better usage details are on following link: PCL documentation PointT types

Titular

Answer 12

From the Wikipedia article on unions:

The primary usefulness of a union is to conserve space, since it provides a way of letting many different types be stored in the same space. Unions also provide crude polymorphism. However, there is no checking of types, so it is up to the programmer to be sure that the proper fields are accessed in different contexts. The relevant field of a union variable is typically determined by the state of other variables, possibly in an enclosing struct.

One common C programming idiom uses unions to perform what C++ calls a reinterpret_cast, by assigning to one field of a union and reading from another, as is done in code which depends on the raw representation of the values.

Bertilla

Answer 13

In the earliest days of C (e.g. as documented in 1974), all structures shared a common namespace for their members. Each member name was associated with a type and an offset; if "wd_woozle" was an "int" at offset 12, then given a pointer p of any structure type, p->wd_woozle would be equivalent to *(int*)(((char*)p)+12). The language required that all members of all structures types have unique names except that it explicitly allowed reuse of member names in cases where every struct where they were used treated them as a common initial sequence.

The fact that structure types could be used promiscuously made it possible to have structures behave as though they contained overlapping fields. For example, given definitions:

struct float1 { float f0;};
struct byte4  { char b0,b1,b2,b3; }; /* Unsigned didn't exist yet */

code could declare a structure of type "float1" and then use "members" b0...b3 to access the individual bytes therein. When the language was changed so that each structure would receive a separate namespace for its members, code which relied upon the ability to access things multiple ways would break. The values of separating out namespaces for different structure types was sufficient to require that such code be changed to accommodate it, but the value of such techniques was sufficient to justify extending the language to continue supporting it.

Code which had been written to exploit the ability to access the storage within a struct float1 as though it were a struct byte4 could be made to work in the new language by adding a declaration: union f1b4 { struct float1 ff; struct byte4 bb; };, declaring objects as type union f1b4; rather than struct float1, and replacing accesses to f0, b0, b1, etc. with ff.f0, bb.b0, bb.b1, etc. While there are better ways such code could have been supported, the union approach was at least somewhat workable, at least with C89-era interpretations of the aliasing rules.

Gladisgladney

Answer 14

Lets say you have n different types of configurations (just being a set of variables defining parameters). By using an enumeration of the configuration types, you can define a structure that has the ID of the configuration type, along with a union of all the different types of configurations.

This way, wherever you pass the configuration can use the ID to determine how to interpret the configuration data, but if the configurations were huge you would not be forced to have parallel structures for each potential type wasting space.

Faubert

Answer 15

One recent boost on the, already elevated, importance of the unions has been given by the Strict Aliasing Rule introduced in recent version of C standard.

You can use unions do to type-punning without violating the C standard.
This program has unspecified behavior (because I have assumed that float and unsigned int have the same length) but not undefined behavior (see here).

#include <stdio.h> 

union float_uint
{
    float f;
    unsigned int ui;
};

int main()
{
    float v = 241;
    union float_uint fui = {.f = v};

    //May trigger UNSPECIFIED BEHAVIOR but not UNDEFINED BEHAVIOR 
    printf("Your IEEE 754 float sir: %08x\n", fui.ui);

    //This is UNDEFINED BEHAVIOR as it violates the Strict Aliasing Rule
    unsigned int* pp = (unsigned int*) &v;

    printf("Your IEEE 754 float, again, sir: %08x\n", *pp);

    return 0;
}

Partial

The type-access rules aren't just in "recent" versions of the Standard. Every version of the C has included essentially the same rules. What has changed is that compilers used to regard the footnote "The intent of this list is to specify those circumstances in which an object may or may not be aliased." as indicating that the rule wasn't meant to apply in cases which didn't involve aliasing as written, but they now treat it as an invitation to rewrite code to create aliasing where there hadn't been any. – Gladisgladney

Answer 16

I would like to add one good practical example for using union - implementing formula calculator/interpreter or using some kind of it in computation(for example, you want to use modificable during run-time parts of your computing formulas - solving equation numerically - just for example). So you may want to define numbers/constants of different types(integer, floating-point, even complex numbers) like this:

struct Number{
enum NumType{int32, float, double, complex}; NumType num_t;
union{int ival; float fval; double dval; ComplexNumber cmplx_val}
}

So you're saving memory and what is more important - you avoid any dynamic allocations for probably extreme quantity(if you use a lot of run-time defined numbers) of small objects(compared to implementations through class inheritance/polymorphism). But what's more interesting, you still can use power of C++ polymorphism(if you're fan of double dispatching, for example ;) with this type of struct. Just add "dummy" interface pointer to parent class of all number types as a field of this struct, pointing to this instance instead of/in addition to raw type, or use good old C function pointers.

struct NumberBase
{
virtual Add(NumberBase n);
...
}
struct NumberInt: Number
{
//implement methods assuming Number's union contains int
NumberBase Add(NumberBase n);
...
}
struct NumberDouble: Number
{
 //implement methods assuming Number's union contains double
 NumberBase Add(NumberBase n);
 ...
}
//e.t.c. for all number types/or use templates
struct Number: NumberBase{
 union{int ival; float fval; double dval; ComplexNumber cmplx_val;}
 NumberBase* num_t;
 Set(int a)
 {
 ival=a;
  //still kind of hack, hope it works because derived classes of   Number    dont add any fields
 num_t = static_cast<NumberInt>(this);
 }
}

so you can use polymorphism instead of type checks with switch(type) - with memory-efficient implementation(no dynamic allocation of small objects) - if you need it, of course.

Miscarriage

This may be useful when making a dynamic language. The problem I think it will solve is modifying a variable of unknown type in mass without implementing that modification N times. Macros are horrendous for this and templating is virtually impossible. – Convalescence

Answer 17

From http://cplus.about.com/od/learningc/ss/lowlevel_9.htm:

The uses of union are few and far between. On most computers, the size of a pointer and an int are usually the same- this is because both usually fit into a register in the CPU. So if you want to do a quick and dirty cast of a pointer to an int or the other way, declare a union.

union intptr {   int i;   int * p; }; 
union intptr x; x.i = 1000; 
/* puts 90 at location 1000 */ 
*(x.p)=90; 

Another use of a union is in a command or message protocol where different size messages are sent and received. Each message type will hold different information but each will have a fixed part (probably a struct) and a variable part bit. This is how you might implement it..

struct head {   int id;   int response;   int size; }; struct msgstring50 {    struct head fixed;    char message[50]; } struct

struct msgstring80 { struct head fixed; char message[80]; }
struct msgint10 { struct head fixed; int message[10]; } struct msgack { struct head fixed; int ok; } union messagetype {
struct msgstring50 m50; struct msgstring80 m80; struct msgint10 i10; struct msgack ack; }

In practice, although the unions are the same size, it makes sense to only send the meaningful data and not wasted space. A msgack is just 16 bytes in size while a msgstring80 is 92 bytes. So when a messagetype variable is initialized, it has its size field set according to which type it is. This can then be used by other functions to transfer the correct number of bytes.

Hummock

Answer 18

Unions provide a way to manipulate different kind of data in a single area of storage without embedding any machine independent information in the program They are analogous to variant records in pascal

As an example such as might be found in a compiler symbol table manager, suppose that a constant may be an int, a float, or a character pointer. The value of a particular constant must be stored in a variable of the proper type, yet it is most convenient for table management if the value occupies the same amount of storage and is stored in the same place regardless of its type. This is the purpose of a union - a single variable that can legitimately hold any of one of several types. The syntax is based on structures:

union u_tag {
     int ival;
     float fval;
     char  *sval;
} u;

The variable u will be large enough to hold the largest of the three types; the specific size is implementation-dependent. Any of these types may be assigned to u and then used in expressions, so long as the usage is consistent

Carnal