Why do compilers not warn about this null dereferencing, even when they detect it?

Question

Consider the following program:

int main() {
    int* ptr = nullptr;
    return *ptr + 1;
}

(also on GodBolt)

How is it, that with "decent" warnings enabled (-Wall -Wextra), both popular compilers - clang++ 20.1.0, g++ 15.1 - fail to warn me about the null pointer dereferencing? Especially since they realize they don't need to bother adding 1?

Note: Same behavior if I compile it as C instead of C++.

Compiler warnings are generally based on static type analysis, not data flow. — Barmar
– Barmar, Commented Jun 11 at 20:19
@Barmar: Re “Compiler warnings are generally based on static type analysis, not data flow”: Not in 2025, and OP has demonstrated the compiler did in fact analyze the data flow and the specific value assigned to ptr. The code GCC generates contains ud2, showing that GCC recognized the behavior is undefined. — Eric Postpischil
– Eric Postpischil, Commented Jun 11 at 20:23
Incrementing a pointer outside the context of an address of an array is undefined behavior. C and C++ compilers are not required to identify undefined behavior. It is the responsibility of the programmer to avoid undefined behavior in C and C++. — Jim Rogers
– Jim Rogers, Commented Jun 12 at 2:17
I think your question boils down to basically why doesn't -Wall mean "all". This is for the authors of GCC to answer. Otherwise it's just opinions. — Galik
– Galik, Commented Jun 12 at 5:40

einpoklum · Accepted Answer · 2025-06-15 09:02:59Z

20

tl;dr: Because you didn't specifically ask for warnings about null dereferencing.

clang and GCC have a specific warning flag for this. Quoting the GCC man page:

-Wnull-dereference
    Warn if the compiler detects paths that trigger erroneous or undefined 
    behavior due to dereferencing a null pointer.  This option is only
    active when -fdelete-null-pointer-checks is active, which is enabled by 
    optimizations in most targets.  The precision of the warnings depends
    on the optimization options used.

I have not observed -fdelete-null-pointer-checks to have any effect on clang and GCC however, only by the optimization level and this flag. Here is how the effects seem to work right now (clang 20, GCC 15.1):

Compiler	Optimization level	`-Wnull-dereference`	Other flags?	Warning?
clang	(none)	On		No
clang	(none)	Off		No
GCC	(none)	On		No
GCC	(none)	Off		No
clang	-O1 or higher	On		No (*)
clang	-O1 or higher	Off		No (*)
GCC	-O1 or higher	On		Yes
GCC	-O1 or higher	Off		No
GCC	(any)	(any)	`-fanalyzer`	Yes

(*) If you fully-hand-inline everything:

int main() {
    return *(int*)(0) + 1;
}

clang will catch the null dereferencing (provided -Wnull-dereference)

What are we seeing here?

A clang bug in the case of -O1 or higher and -Wnull-dereference. Thanks @n.m.canbeai for suggesting that. It is bug 113068, already reported last year.
Both compilers are being very lazy in their static analysis even when you ask them for -Wnull-dereference. Is this a good idea? I would say no, or at least - you should be able to tell the compiler "even though I'm not asking for optimization, I do want you to statically analyze seriously".
Both compilers don't believe that checking for null dereferences should be part of "all" warnings, nor even part of the "extra" warnings. IMNSHO that is quite bad, since a user is quite likely to assume that this check is part of one of those two.
Both compilers avoid warning about null-dereferencing when not explicitly asked to do so, despite detecting - at some level - that it happens, and despite not being asked to suppress all warnings. This is not as bad, but still somewhat questionable.
GCC's static analyzer, applicable from "within" the compiler, helps (at least in some cases).

edited Jun 15 at 9:02

answered Jun 12 at 9:40

einpoklum

137k86 gold badges445 silver badges917 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Matthieu M. Jun 14 at 13:57

From the bug you linked, this comment by Aaron Ballman is fairly interesting: "In order to support this, we need to build a CFG". That is, Clang still has this odd architecture where it skips building a CFG (of its own), and instead goes directly from typed AST to LLVM IR. Contrast with rustc, which builds MIR (a CFG) and then lowers MIR to LLVM IR, which allows rustc to run control-flow diagnostics "for cheap", since the CFG is already built.

Marc Glisse Jun 15 at 8:57

Did you try gcc's -fanalyzer? (C++ support is very preliminary, but the testcase is essentially C)

einpoklum Jun 15 at 9:03

@MarcGlisse: I did and it detects the null-dereference. See edit.

Collectives™ on Stack Overflow

Why do compilers not warn about this null dereferencing, even when they detect it?

1 Answer 1

tl;dr: Because you didn't specifically ask for warnings about null dereferencing.

3 Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

tl;dr: Because you didn't specifically ask for warnings about null dereferencing.

3 Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related