What information do C variables contain under the hood?

Question

I'm working through K&R C and this line stood out to me:

A pointer is a variable that contains the address of a variable.

I always assumed (perhaps incorrectly) that a variable under the hood must contain a name, type, and the address of some location in memory. Ie: while variables can be treated as values, the compiler must know where those values are stored in memory, so variables must also be pointers (conceptually, not formally).

But now I'm not so sure. The text seems to imply that variables are somehow more fundamental than pointers.

What are variables, really? Are they like pointers under the hood, or are they different in some way? Specifically looking to understand this in the context of how memory is allocated.

EDIT: For those engaging in semantic debates... I am interested in understanding the _average_ use case, not what the standard does or doesn't specify, though I should have specified. For functional purposes, let's say C compiled with gcc or similar on a unix machine. Thanks!

Answer 1

What exactly constitutes a "variable" differs from language to language. It also matters what kind of a runtime environment is used - native binary (C/C++/Fortran/Cobol/Pascal), bytecode in a virtual machine (Java/C#/Scala/F#), a source-level interpreter (old-skool BASIC, bash/csh/sh), etc.

In the case of C, a variable is simply a chunk of memory large enough to hold the value of the specified type - there is no metadata associated with that memory chunk that tells you anything about its name (which typically isn't preserved in the machine code), its type, whether it's part of an array or not, etc. IOW, if you examined an integer variable in memory in a running program, all you'd see is the value stored in that integer. You wouldn't see any other information stored about that variable.

During translation (i.e., while the code is being compiled), the compiler maintains an internal table that keeps track of variables, variable names, types, scope, visibility, etc. However, none of that information (usually) makes it into the generated machine code. auto (local) variables are typically referred to by an offset from given stack address. static variables typically have a fixed address. Values of different types are dealt with by using different machine code instructions (for example, there are usually separate instructions for dealing with integers vs. floats).

A pointer variable simply stores an address. The exact format of that address will vary based on the system, but on modern x86 and similar systems, it's essentially an unsigned integer value. On a segmented memory system, it may be a pair of values (page # and offset).

EDIT

C code is typically compiled into a native binary (although there's at least one compiler that targets the Java VM, and there may be compilers that target other virtual machines). On an x86-like system, a running native binary is typically laid out like this in (virtual!) memory:

              +-------------------------+
High address: | Environmental variables |
              | and command line args   |
              +-------------------------+
              |        Stack            |
              |          |              |
              |          V              |
              |          ^              |
              |          |              |
              |         Heap            |
              +-------------------------+
              | Read-only data items    |
              +-------------------------+
              | Global data items       |
              +-------------------------+
              | Program text (machine   |
 Low address: | code)                   |
              +-------------------------+

The exact details vary from system to system, but this is a decent overall view.

Each time a function is called (including main), memory is taken from the stack to build what is called a stack frame. The stack frame contains space for the function arguments (if any), local variables (if any), address of the previous stack frame, and the address of the next instruction to execute after the function returns.

              +--------------------+
High address: | Function arguments |
              +--------------------+
              | Return address     |
              +--------------------+
              | Prev frame address | <-- %rbp/%ebp (frame pointer)
              +--------------------+
 Low address: | Local variables    | <-- %rsp/%esp (stack pointer)
              +--------------------+ 

The %rsp (64-bit) or %esp (32-bit) register stores the address of the top of the stack (on x86, the stack grows "down" towards decreasing addresses), and the %rbp (64-bit) or %ebp (32-bit) register stores the address of the stack frame. Function arguments and local variables are referred to via offsets from the frame pointer, such as

-4(%rpb) -- object starting 4 bytes "below" current frame address
32(%rbp) -- object starting 32 bytes "above" current frame address

Here's an example - we have a function foo that takes two int arguments and has two int local variables:

#include  <stdio.h>

void foo( int x, int y )
{
  int a;
  int b;

  a = 2 * x + y;
  b = x - y;

  printf( "x = %d, y = %d, a = %d, b = %d\n", x, y, a, b );

}

Here's the generated assembly for that function (MacOS 10.13, LLVM version 9.1.0):

        .section        __TEXT,__text,regular,pure_instructions
        .macosx_version_min 10, 13
        .globl  _foo                    ## -- Begin function foo
        .p2align        4, 0x90
_foo:                                   ## @foo
        .cfi_startproc
## BB#0:
        pushl   %ebp
Lcfi0:
        .cfi_def_cfa_offset 8
Lcfi1:
        .cfi_offset %ebp, -8
        movl    %esp, %ebp
Lcfi2:
        .cfi_def_cfa_register %ebp
        pushl   %ebx
        pushl   %edi
        pushl   %esi
        subl    $60, %esp
Lcfi3:
        .cfi_offset %esi, -20
Lcfi4:
        .cfi_offset %edi, -16
Lcfi5:
        .cfi_offset %ebx, -12
        calll   L0$pb
L0$pb:
        popl    %eax
        movl    12(%ebp), %ecx
        movl    8(%ebp), %edx
        leal    L_.str-L0$pb(%eax), %eax
        movl    8(%ebp), %esi
        shll    $1, %esi
        addl    12(%ebp), %esi
        movl    %esi, -16(%ebp)
        movl    8(%ebp), %esi
        subl    12(%ebp), %esi
        movl    %esi, -20(%ebp)
        movl    8(%ebp), %esi
        movl    12(%ebp), %edi
        movl    -16(%ebp), %ebx
        movl    %eax, -24(%ebp)         ## 4-byte Spill
        movl    -20(%ebp), %eax
        movl    %eax, -28(%ebp)         ## 4-byte Spill
        movl    -24(%ebp), %eax         ## 4-byte Reload
        movl    %eax, (%esp)
        movl    %esi, 4(%esp)
        movl    %edi, 8(%esp)
        movl    %ebx, 12(%esp)
        movl    -28(%ebp), %esi         ## 4-byte Reload
        movl    %esi, 16(%esp)
        movl    %edx, -32(%ebp)         ## 4-byte Spill
        movl    %ecx, -36(%ebp)         ## 4-byte Spill
        calll   _printf
        movl    %eax, -40(%ebp)         ## 4-byte Spill
        addl    $60, %esp
        popl    %esi
        popl    %edi
        popl    %ebx
        popl    %ebp
        retl
        .cfi_endproc
                                        ## -- End function
        .section        __TEXT,__cstring,cstring_literals
L_.str:                                 ## @.str
        .asciz  "x = %d, y = %d, a = %d, b = %d\n"


.subsections_via_symbols

Here's what our stack frame will look like:

              +---+
High address: | y |
              +---+
              | x |
              +---+
              |   | return address
              +---+
              |   | address of previous frame
              +---+
              | a |
              +---+
              | b |
              +---+

Now, that's how things look in 32-bit world. 64-bit gets a little more complicated - some function arguments are passed in registers rather than on the stack, so the nice neat picture above breaks down.

Now, I'm talking about the concept of a variable at runtime, which is what I think you were asking about.

Answer 2

I always assumed (perhaps incorrectly) that a variable under the hood must contain a name, type, and the address of some location in memory.

This is wrong, at least for C11. The definitive reference is the standard specification, e.g. n1570 (actually a late draft identical to the ISO standard)

In practice, a variable is usually some memory location. It has some value, but the name and type is forgotten at runtime. Only the compiler knows about the name and type of the variable. The compiler may sometimes (under the as-if rule) forget a variable if it is optimizing.

A pointer don't refer to a variable, but to a memory location.

Read also about undefined behavior.

Answer 3

variable is C abstract thing and has only the name in the source code (It is placed as well in the object file (if the compiler generates them) - but it outside the scope of this deliberations). In the compiled (and potentially linked) executable file there are no variables - there are only some locations in the memory or registers, which are manipulated by the machine code instructions.

Variable is an language abstraction, and they do not exist outside the source code scope. SIn the source code variable has the name and type. In the executable file variables as we understand it in the C language do not exist.

Answer 4

A variable is a symbolic representation of a particular location in memory.

That location holds the type and value that is associated with the variable. The data that is stored in that memory location can change, hence the term variable.

And as pointed out above, a pointer is a variable in which the type is pointer and the value is an address in memory.

Answer 5

A variable represents an object that contains some data and has a certain type. The data is always stored physically in binary forms in memory. The type of the object decides how the data is interpreted.

So a pointer is such an object that the data it contains is an address in the memory, and the type is "a pointer to another object".

The object that a variable refers to is also a solid object, so it has properties like size and location (memory addr.) of its own. This does not interfere with what it contains (what its "data" is).

Consider a live example. A road sign may points to another location, but the sign itself is located somewhere. The two locations do not interfere and can even be the same (though usually no one does that).

Answer 6

Copying blatantly from the wikipedia article, (emphasis mine)

In computer programming, a variable or scalar is a storage location (identified by a memory address) paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of information referred to as a value. The variable name is the usual way to reference the stored value, in addition to referring to the variable itself, depending on the context. This separation of name and content allows the name to be used independently of the exact information it represents. The identifier in computer source code can be bound to a value during run time, and the value of the variable may thus change during the course of program execution. [....]

Then, going forward

... so variables must also be pointers ...

Well, not really. Just because, variables are associated with an address, does not make them of pointer type.

To add, a pointer type, can also be a variable - basically a variable which holds the address for another type (of variable or constant object).

To present is graphically, let's consider two variables,

• int a - a variable named a of type int, (assume integer size is 4 bytes)
• int *ptr - a variable named ptr of type int *, (assume pointer size is 4 bytes)

and we say, ptr = &a;

As above:

 +--------------------+
 |                    |
 |                    |
 +--------------------+

 8000       a         8003

 // Here you have four bytes, ranging from 8000 to 8003, indicated by variable `a`

 +----------------------+
 |                      |
 |                      |
 +----------------------+

9000        ptr         9003

 // Here you have four bytes, ranging from 9000 to 9003, indicated by variable `ptr`
 // next, as we say ptr = &a;

 +----------------------+
 |                      |
 |         8000         |
 +----------------------+

9000        ptr         9003

//ptr now holds the address of variable `a`.
// however, ptr still has it's own address, as it itself, is a variable.

Answer 7

Suppose you have these variables:

int x = 1234;
void f(void) {
    int y = 4567;
}

The compiler discards the names x and y and the type int and just remembers the addresses of the variables (it can keep names in a symbol map for debugging, but these are not needed otherwise).

Static variables like x have a fixed address, so when your code does something with x you are telling the compiler to do something with the value held at this fixed address.

Automatic variables like y are often held in a register. The compiler generates code to look at the value of that register. Or the compiler might store it in f()'s stack frame, so it will generate code that looks at the content of an address that is offset from that stack frame address.

A variable that is a pointer works in the same way, except that instead of storing a value like an int it stores the address of another variable.