Poor handling of uninitialized variables about smack HOT 5 CLOSED

I investigated this a little bit. And as I expected, LLVM's mem2reg pass optimizes this code so that it completely forgets about a and introduces two fresh undef values. Which is probably fine based on C semantics, which most likely says that if a variable is uninitialized, anything can be used as its value. The problem is that __SMACK_assume is "special" function call in SMACK, which LLVM does not understand.

One solution would be to do this:

int main(void) {
  int a = __SMACK_nondet();
  __SMACK_assume(a == 1);
  __SMACK_assert(a == 1);
  return 0;
}

Unfortunately, currently no other brilliant fixes come to my mind. I am not even sure if this should be fixed...

from smack.

Now I am leaning towards not trying to fix this. Users simply shouldn't use uninitialized variables and you even get a warning about that from clang.

from smack.

Mike, please confirm that you are ok if we do not fix this. Given what C standard says, this assertion should in fact fail.

from smack.

I agree that we have nothing to fix here; our current handling is compliant with both C and LLVM semantics, as noted here: http://llvm.org/docs/LangRef.html#undefined-values

However, I slightly disagree with your assessment, that the problem is that "__SMACK_assume is a special function call ... which LLVM does not understand." Even if LLVM did have an assume statement, the result would be the same: the assume a == 1 need not have any impact since a is undefined, and according to the aforementioned URL:

An undef "variable" can arbitrarily change its value over its "live range".
This is true because the variable doesn’t actually have a live range.
Instead, the value is logically read from arbitrary registers that happen to be
around when needed, so the value is not necessarily consistent over time.

In other words, the value of a in the first (assume) statement need not have anything to do with the value of a in the second (assert) statement.

from smack.

Yes, I absolutely agree with you Mike. What I wrote before was not completely correct, as I learned several weeks ago after a lengthy discussion with several people on social networks.

from smack.