[Feature Request] Memory sanitiser poisoning idiom which works with static analyser.

[sh1boot]

In order to both initialise a variable with a known value, but also assert to the static analyser and to MSAN that I still don't know what it should be, I was trying to do make an idiom like this work:

int x = provisional(-1);
// ...
if (foo) x = 10;
// ...
f(x);

So that the code could be diagnosed as erroneous when foo is false.

Or:

ErrorCode function(ResultType& result, int argument) {
    result = provisional(ResultType{});
    if (argument == derpyderp) {
        return DerpyError;
    }
    // ...
    result = sensible_value;
    // ...
    if (ActuallyNevermind) {
        result = provisional(ResultType{});
        return AhhhForgetIt;
    }
    // ...
    return OK;
}

(alternatively provisional<int>(-1) with smart defaults like provisional<double>(double init = signalling_NaN))

And it looks like as far as MSAN is concerned this does work (with huge caveats):

template <typename T>
[[gnu::always_inline]] T provisional(T init) {
    T tmp{init};
#if __has_feature(memory_sanitizer)
    __msan_poison(&tmp, sizeof(tmp));
#endif
    return tmp;
}

But this can only raise errors at run time, iff you have adequate test coverage. While it actually blocks compile-time diagnosis of faulty code.

There needs to be a construct that lets all the tools produce the best outcomes achievable for each of them. Where static analysis stills regards the variable as uninitialised, where MSAN does the same, and where release code has a known safe value inserted as a predictable backstop (a value the developer has clearly never tested, but at least it's not a leak!).

C++26 adds [[indeterminate]] but that's very much the opposite -- taking away the safe default without asking the other tools to watch the variable more closely.

Does this need to be a compiler extension?

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: S H (sh1boot)

In order to both initialise a variable with a known value, but also assert to the static analyser and to MSAN that I _still_ don't know what it should be, I was trying to do make an idiom like this work:

int x = provisional(-1);
// ...
if (foo) x = 10;
// ...
f(x);

So that the code could be diagnosed as erroneous when foo is false.

Or:

ErrorCode function(ResultType& result, int argument) {
    result = provisional(ResultType{});
    if (argument == derpyderp) {
        return DerpyError;
    }
    // ...
    result = sensible_value;
    // ...
    if (ActuallyNevermind) {
        result = provisional(ResultType{});
        return AhhhForgetIt;
    }
    // ...
    return OK;
}

(alternatively provisional<int>(-1) with smart defaults like provisional<double>(double init = signalling_NaN))

And it looks like as far as MSAN is concerned this does work (with huge caveats):

template <typename T>
[[gnu::always_inline]] T provisional(T init) {
    T tmp{init};
#if __has_feature(memory_sanitizer)
    __msan_poison(&tmp, sizeof(tmp));
#endif
    return tmp;
}

But this can only raise errors at run time, iff you have adequate test coverage. While it actually blocks compile-time diagnosis of faulty code.

There needs to be a construct that lets all the tools produce the best outcomes achievable for each of them. Where static analysis stills regards the variable as uninitialised, where MSAN does the same, and where release code has a known safe value inserted as a predictable backstop (a value the developer has clearly never tested, but at least it's not a leak!).

C++26 adds [[indeterminate]] but that's very much the opposite -- taking away the safe default without asking the other tools to watch the variable more closely.

Does this need to be a compiler extension?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: S H (sh1boot)

In order to both initialise a variable with a known value, but also assert to the static analyser and to MSAN that I _still_ don't know what it should be, I was trying to do make an idiom like this work:

int x = provisional(-1);
// ...
if (foo) x = 10;
// ...
f(x);

So that the code could be diagnosed as erroneous when foo is false.

Or:

ErrorCode function(ResultType& result, int argument) {
    result = provisional(ResultType{});
    if (argument == derpyderp) {
        return DerpyError;
    }
    // ...
    result = sensible_value;
    // ...
    if (ActuallyNevermind) {
        result = provisional(ResultType{});
        return AhhhForgetIt;
    }
    // ...
    return OK;
}

(alternatively provisional<int>(-1) with smart defaults like provisional<double>(double init = signalling_NaN))

And it looks like as far as MSAN is concerned this does work (with huge caveats):

template <typename T>
[[gnu::always_inline]] T provisional(T init) {
    T tmp{init};
#if __has_feature(memory_sanitizer)
    __msan_poison(&tmp, sizeof(tmp));
#endif
    return tmp;
}

But this can only raise errors at run time, iff you have adequate test coverage. While it actually blocks compile-time diagnosis of faulty code.

There needs to be a construct that lets all the tools produce the best outcomes achievable for each of them. Where static analysis stills regards the variable as uninitialised, where MSAN does the same, and where release code has a known safe value inserted as a predictable backstop (a value the developer has clearly never tested, but at least it's not a leak!).

C++26 adds [[indeterminate]] but that's very much the opposite -- taking away the safe default without asking the other tools to watch the variable more closely.

Does this need to be a compiler extension?

[steakhal]

My instinct would suggest to utilize the __clang_analyzer__ macro and define the behavior that should be used for analysis and outside of that conditional complied code define the actual code that you intend to ship.
https://clang.llvm.org/docs/analyzer/user-docs/FAQ.html#excluding-code-from-analysis

https://godbolt.org/z/M8bsWfrPo

#include <cstdio>

void clang_analyzer_warnIfReached(int param) {
  printf("clang_analyzer_warnIfReached %d\n", param);
}

int *new_uninitialized_memory() {
  int *p = new int;
#ifndef __clang_analyzer__
  // Just to be on the safe side, initialize this piece of memory at runtime,
  // but still consider it uninitialized during analysis
  *p = 0xdeadbeef;
#endif
  return p;
}

int main() {
  int *p = new_uninitialized_memory();
  if (*p) { // kills the analysis as reading garbage is poison for the analyzer
    clang_analyzer_warnIfReached(1); // taken at runtime, due to the conservative initialization
  } else {
    clang_analyzer_warnIfReached(2); // unreachable
  }
  delete p;
}

[sh1boot]

Is there some way to get uninitialised-ness into an existing object, though? Like, in my template example I have T tmp{init}; which, logically, I would change to T tmp;, but of course when I do that I get the analyser's complaint inside the provisional() function rather than having that poison silently moved into the destination object and raising a complaint later (of course it's always going to be a question when to propagate versus when to raise a fault; and MSAN seems to have the opposite problem of overlooking the poisoned state of memory when you do simple arithmetic on it rather than returning it or passing it to another function).

It's important because what I really want to see being possible is "what's in this variable is not the thing you want, and if you access it by accident then there's a logic bug that needs fixing", and this is a condition that can arise not just at definition or allocation of a variable, but after something goes wrong and what was put in there needs to be scrubbed out again (like when a decoded message fails its integrity check and mustn't be used).

Best I could think of was:

#if defined __clang_analyzer__
#define PROVISIONAL(x)
#else
#define PROVISIONAL(x) =(x)
#endif

...
int x PROVISIONAL(-1);

But that can't re-assert the undefined state of the variable after initialisation.

Maybe something like std::move but poison_move() instead, to silently propagate uninitialised-ness from one place to another without raising any fault on the operation per se.

[steakhal]

I'm sorry that it took me so long to get back here.

I'm still not sure I fully understand this problem. To me, initializedness come from the variable declaration.
I think I'd need to see a minimal but still sensible complete example to see what we could do about it.