Is passing an uninitialized variable to another function UB

Question

I wonder is it true that just passing an uninitialized variable to a function results in an undefined behavior?

It seems really weird for me.

Suppose that we have the following code:

void open_db(db* conn)
{
  // Open database connection and store it in the conn
}

int main()
{
  db* conn;
  open_db(conn);
}

It seems perfectly legal to me. It doesn't dereference an uninitialized variable nor it doesn't relay on its state. It just passes an uninitialized pointer to another function that stores some data in it via operator new or something like this.

If it's UB, could you quote the exact place where the Standard says so?

And is it also true for other types like int?

void foo(int bar)
{
  // ...
}

int main()
{
  int bar;
  foo(bar); // UB?
}

Answer 1

It is UB, and the type of the argument does not matter. The relevant bits of C99 are: when you declare a variable with "automatic storage duration" but don't initialize it, its value is indeterminate (6.2.4p5, 6.7.8p10); any use of an indeterminate value provokes undefined behavior (J.2 refers to 6.2.4, 6.7.8, and 6.8)¹.

And even if it wasn't UB (for instance if conn had been initialized)., this code would not have the effect you seem to expect it to have. As written, open_db cannot modify the variable conn in its caller.

A slight variation on your code is valid whether or not conn is initialized, and does do what you expect it to do, though:

void open_db(db **conn)
{
  *conn = internal_open_db();
}

int main()
{
  db *conn;
  open_db(&conn);
}

The address-of operator, unary &, is one of the very few things in the language that does not provoke undefined behavior when applied to an uninitialized variable, because it does not read the value of the variable. It only determines the memory location of the variable. That is a determinate value, that can safely be passed to open_db (but note that its type signature has changed: it is now receiving a pointer to a pointer to a db. And open_db can now use the pointer-dereference operator, unary *, to write a result into the variable.

In C++ only, this very common pattern receives a bit of syntactic sugar:

void open_db(db *&conn)
{
  conn = internal_open_db();
}

int main()
{
  db *conn;
  open_db(conn);
}

Changing the second star to an ampersand makes the conn argument to open_db now a "reference" to a pointer. It's still a pointer to a pointer "under the hood", but the compiler fills in the & and * operators for you as necessary.

---

¹ For my fellow language lawyers: Annex J is non-normative, and I can't find any normative statement backing up its assertion that using an indeterminate value is always UB. (It might help if I could find a definition of what it means to "use a value" in the first place. I believe the intent was anything that triggers 6.3.2.1p2 "lvalue conversion", but I don't think that's ever actually stated.)

The definition of an "indeterminate value" is "an unspecified value or a trap representation"; using an unspecified value does not provoke UB. Using a trap representation does provoke UB, but not all types have trap reps. C11, but not C99, has a sentence in 6.3.2.1p2 that states quite baldly "if [the code reads a value from] an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized, the behavior is undefined" -- but note that it doesn't use the term-of-art "indeterminate value" here, and it restricts the rule to variables whose address is not taken.

However, C compilers absolutely do treat reading any uninitialized variable as UB regardless of whether its type has trap reps or whether its address has been taken, and J.2 certainly reflects the intent of the committee, as do a number of examples in clause 7 where the word "indeterminate" appears solely to point out that reading some variable is UB.

Answer 2

This generates warning:

int a;
int b = a; //warning, a is uninitialized, but is USED to initialize b, UB

Since using variable with Uspecified Value is UB, passing uninitialized variable to function by value should result the same, since it involves copying - yet no checking is done by compiler so no warning is generated.

If this isn't some amazing exception, this is definitely Undefined Behaviour.

Answer 3

In C: This thread covers all the issues related to reading uninitialized variables, it's somewhat complicated.

Passing a variable by value to a function requires reading it, obviously.

For C++14 see this answer.

Both of your code samples are undefined behaviour in both languages.

Answer 4

In the example you give

void open_db(db* conn)
{
  // Open database connection and store it in the conn
}

int main()
{
  db* conn;
  open_db(conn);
}

the variable, conn, in main is an uninitialized pointer.

You then pass a copy of that to open_db. You are not passing the address of the pointer, you are passing the uninitialized value as an address-of.

This requires a read of an uninitialized address in order to populate the copy used in db_conn.

The compiler is free to recognize this and either perform the read with potential undefined behavior consequences (it is feasible that the program might crash performing such a read) or the compiler might elide the copy and just let db_conns conn parameter be differently undefined.

Based on other comments I've read, I believe you're trying to be clever and say "Aha! But I always initialize conn inside db_conn and never read it without initializing it".

Ok... That's ... perverse.

void db_conn(db* conn)
{
    db* new_conn = db_connection_helper();
    if (!new_conn) {
        log_error("Couldn't open database");
        return;
    }
    log_success("Opened database");
    conn = new_conn;
    configure_db_connection(conn);  // first read: guaranteed initialized
    setup_stored_procedures(conn);
}

In this function, conn was passed by value, so conn is a copy of whatever argument was passed to us. Any assignments made to it in the body of db_conn are invisible to the caller.

Indeed, the optimizer is quite likely to treat this code

    conn = new_conn;
    configure_db_connection(conn);  // first read: guaranteed initialized
    setup_stored_procedures(conn);

as

    configure_db_connection(new_conn);  // first read: guaranteed initialized
    setup_stored_procedures(new_conn);

We can easily see this in the assembly

typedef struct db_t {} db;

extern db* db_conn_helper();
extern void db_configure(db*);

void db_conn1(db* conn)
{
  db* new_conn = db_conn_helper();
  if (!new_conn)
    return;
  conn = new_conn;
  db_configure(conn);
}

void db_conn2(db* conn)
{
  db* new_conn = db_conn_helper();
  if (!new_conn)
    return;
  db_configure(new_conn);
}

produces

db_conn1(db_t*):
        subq    $8, %rsp
        call    db_conn_helper()
        testq   %rax, %rax
        je      .L1
        movq    %rax, %rdi
        addq    $8, %rsp
        jmp     db_configure(db_t*)
.L1:
        addq    $8, %rsp
        ret
db_conn2(db_t*):
        subq    $8, %rsp
        call    db_conn_helper()
        testq   %rax, %rax
        je      .L5
        movq    %rax, %rdi
        addq    $8, %rsp
        jmp     db_configure(db_t*)
.L5:
        addq    $8, %rsp
        ret

So this means that if your code tries to use db in main, you're still seeing undefined behavior:

int main() {
    db* conn;  // uninitialized
    db_conn(conn);  // passes uninitialized value
    // our 'conn' is still uninitialized
    query(conn, "SELECT \"undefined behavior\" FROM DUAL");  // UB
}

Perhaps you either mean't

conn = db_conn();  // initializes conn

or

db_conn(&conn);  // only undefined if db_conn tries to use *conn

this requires db_conn to take db**.

db* conn => uninitialized
db** &conn => initialized pointer to an uninitialized db* pointer