-4
// 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?

closed as off-topic by gnat, 17 of 26, Bart van Ingen Schenau, Caleth, Sebastian Redl Apr 30 at 14:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking for assistance in explaining, writing or debugging code are off-topic here. These can be asked on Stack Overflow if they include the desired behavior, a specific problem or error, and the shortest code necessary to reproduce it in the question (see Minimal, Complete, and Verifiable Example)." – gnat, 17 of 26, Bart van Ingen Schenau, Caleth
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    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 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 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 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 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 at 13:19
2

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).

  • 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 at 13:11
  • @JoopEggen Agreed. This solution while novel, has some security concerns. – Akiva Apr 30 at 13:14
  • 1
    @JoopEggen I agree and added a note to the answer. – pschill Apr 30 at 14:05
0
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.

  • That is giving me a random value completely dissimilar to the value proclivity of int i;. – Akiva Apr 30 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 at 14:19

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