// Default initialization
int i;    // i has an unspecified value
return i; // Probably 0, but Unreliable
i = 5;    // i has a specified value
i = int();// This will give it a specified value, 0
i = int{};// This will give it a specified value, 0
return i; // Reliable, no good!
int j;    // Workaround, obvious performance penalties
i = j;    // Also seems a bit too verbose, making code unreadable. 
i = *new int; // Doesn't seem like a good idea.

What's the proper way to unspecify i, or unassign its value, and make it unreliable again?

  • 4
    Your question makes no sense. Why would you ever want to do that? You also seem to misunderstand what Undefined Behavior means. "obvious performance penalties" is completely wrong; since you're provoking UB, you can't predict anything. – Sebastian Redl Apr 30 '19 at 12:50
  • 2
    "How do you return I to its initial state, int i;?" - Again, why? "I will have to create a new object" - You assume that declaring an int local variable does anything whatsoever in the compiled code. You're wrong. – Sebastian Redl Apr 30 '19 at 12:54
  • 4
    "I want an unreliable return value." - You can't. Using an uninitialized variable is undefined behavior, not "an unreliable value". Call rand() or the full RNG machinery if you want something unreliable. "As to declaring a local variable, it depends on the compiler and what you do with the variable, does it not?" - Yes, of course; my point is that your assumption of performance penalty is wrong. – Sebastian Redl Apr 30 '19 at 13:03
  • 2
    @Akiva, would it be acceptable if the program displays a rude message during important demos? Because that is also behavior that you could get from using an uninitialized value (especially if you run your program on a DS9000) – Bart van Ingen Schenau Apr 30 '19 at 13:11
  • 5
    Undefined behaviour is not "we don't know the value here", it can include "there is no value, nor anything dependant on it", or exhibit "impossible" behaviour – Caleth Apr 30 '19 at 13:19

I don`t see any point in doing this, but you could just copy the value of another uninitialized integer:

void uninitialize(int& x)
    int a;
    x = a;

You should also be aware that reading the value of an uninitialized variable is undefined behavior. Compilers may do something meaningful here, but they are not required to.

Many compilers just reuse existing memory for a, which means that a may contain bytes of sensitive data. This function should not be used if you care about security (which you should).

| improve this answer | |
  • 1
    Very nice solution, though one picks a prior stack value, which - as a real unitialized variable - exposes a bit of possibly sensitive data. – Joop Eggen Apr 30 '19 at 13:11
  • @JoopEggen Agreed. This solution while novel, has some security concerns. – Akiva Apr 30 '19 at 13:14
  • 1
    @JoopEggen I agree and added a note to the answer. – pschill Apr 30 '19 at 14:05
i = (int) (rand() * 10E9); // Some random value.

In contrast to JavaScript, there is no unitialized/undefined value. As soon as the variable walks out of scope it's primitive value is lost.

One sometimes sees a zeroing or such in security relevant contexts, nulling secret values.

| improve this answer | |
  • That is giving me a random value completely dissimilar to the value proclivity of int i;. – Akiva Apr 30 '19 at 13:12
  • 2
    An unitialized variable will point to somewhere in memory where anything can be visible, the remains of old variables or whatever. This is especially yummy for a char*. The only purpose of a reunitialisation is to have garbage in the variable. If you want to have some unitialized state of a variable, maybe use optional<int>. Or store the original value: int i; int bah = i; ....; i = bah; – Joop Eggen Apr 30 '19 at 14:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.