-Wuninitialized ignored if type is "const" pointer

[llvmbot]

Bugzilla Link	38112
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@dwblaikie,@rnapier

Extended Description

Compile the following with '-Wuninitialized' and clang fails to diagnose the uninitialized variable.

------------------- test.c -----------------------
extern void foo(const char *p);

int main(){
char *p;
foo(p); // Should produce warning but doesn't
}

---

If "const" is removed from the parameter to "foo", the warning is emitted as expected.

[llvmbot]

I believe it's not a bug. If p is a non-const pointer, it can be used to return a value to the caller. In that case p is an output parameter, which can be initialized by the callee.

If p is a const pointer, the callee would not be allowed to modify the data p is pointing to. If the parameter cannot be used for output, it should be used for input. If the input data is not initialized, a warning is needed.

[llvmbot]

How can this possibly not be a bug? "p" is uninitialized and is being passed as an argument. That means that if "foo" were to pass the pointer to, say, printf, it could crash.

There is no reason to treat an uninitialized "const char* p" differently from an uninitialized "char* p".

[dwblaikie]

yeah, it's probably a reasonable bug - likely the clang diagnostic isn't seeing through the implicit conversion from non-const char* to const-char*.

[llvmbot]

I was completely wrong, please ignore my previous comment.

[rnapier]

This diagnostic similarly fails when using &:

------------------- test.c -----------------------

typedef struct {
int value;
} config_t;

void apply_config(const config_t *config) {
}

int main(int argc, const char *argv[])
{
config_t config;
apply_config(&config); // Should produce warning but doesn't

return 0;

}

---

GCC treats these as different cases. The original case is found by -Wuninitialized since around 4.4, while this case is found by -Wmaybe-uninitialized only since around 11.1. https://godbolt.org/z/Wh7vbf4Wx