Consider:
```
void main()
{
    int* p;
    *p = 3;
}
```
Compiling it and running it results in "Segmentation fault (core dumped)".

But compiling it with -O results in a compile time error:

```
Error: null dereference in function _Dmain
```

What's happening here? The optimizer does DFA (Data Flow Analysis) and can statically determine that `p` is null when deferenced.

(The message is a bit generic because the optimizer turns the source code into hamburger, and the cow is not easily reconstructed.)

Curiously, compiling it with `gcc -O3` does not detect it. ImportC doesn't detect it, either, a choice made because some C code uses such a construct as a way to drop into the debugger.

On 11/01/2025 2:43 PM, Walter Bright wrote:
> Curiously, compiling it with `gcc -O3` does not detect it. ImportC doesn't detect it, either, a choice made because some C code uses such a construct as a way to drop into the debugger.

Yeah you didn't turn the warning on.

```c
int main() {
    int* ptr;
    *ptr = 3;
    return 0;
}
```

flags: ``-Wnull-dereference -O``

```
<source>: In function 'main':
<source>:5:10: warning: null pointer dereference [-Wnull-dereference]
    5 |     *ptr = 3;
      |     ~~~~~^~~
ASM generation compiler returned: 0
<source>: In function 'main':
<source>:5:10: warning: null pointer dereference [-Wnull-dereference]
    5 |     *ptr = 3;
      |     ~~~~~^~~
Execution build compiler returned: 0
Program returned: 139
Program terminated with signal: SIGSEGV
```

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

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

For clang:

flags: ``-Wall --analyze``

```
<source>:5:10: warning: Dereference of null pointer (loaded from variable 'ptr') [core.NullDereference]
    5 |     *ptr = 3;
      |      ~~~ ^
1 warning generated.
ASM generation compiler returned: 0
clang: warning: -Wl,-rpath,./lib: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: -Wl,-rpath,/opt/compiler-explorer/gcc-13.2.0/lib64: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: -Wl,-rpath,/opt/compiler-explorer/gcc-13.2.0/lib32: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L./lib' [-Wunused-command-line-argument]
<source>:5:10: warning: Dereference of null pointer (loaded from variable 'ptr') [core.NullDereference]
    5 |     *ptr = 3;
      |      ~~~ ^
1 warning generated.
Execution build compiler returned: 0
Program returned: 255
```

For MSVC:

flags: ``/analyze``

```
<source>(5) : warning C6011: Dereferencing NULL pointer 'ptr'. : Lines: 4, 5
ASM generation compiler returned: 0
example.c
<source>(5) : warning C6011: Dereferencing NULL pointer 'ptr'. : Lines: 4, 5
Execution build compiler returned: 0
```

Interesting, I get a different error from GCC:


```
$ gcc -g -O2 -std=c11 -Wall -Wextra -Wpedantic -Werror null.c
null.c:1:6: error: return type of ‘main’ is not ‘int’ [-Werror=main]
    1 | void main()
      |      ^~~~
null.c: In function ‘main’:
null.c:4:8: error: ‘p’ is used uninitialized [-Werror=uninitialized]
    4 |     *p = 3;
      |     ~~~^~~
cc1: all warnings being treated as errors
```

Which is more accurate, as there is no guarantee an uninitialised auto pointer will actually be NULL, rather than arbitrary garbage.

That is GCC 11.4.0, using GCC 12.3.0 adds:

```
null.c:3:10: note: ‘p’ was declared here
    3 |     int* p;
      |          ^
cc1: all warnings being treated as errors
```

After correcting the return type, and adding a return 0, clang 14.0.0 gives me:

```
$ clang-14 -g -O2 -std=c11 -Wall -Wextra -Wpedantic -Werror null.c
null.c:4:6: error: variable 'p' is uninitialized when used here [-Werror,-Wuninitialized]
    *p = 3;
     ^
null.c:3:11: note: initialize the variable 'p' to silence this warning
    int* p;
          ^
           = 0
1 error generated.
```

On 1/10/2025 6:01 PM, Richard (Rikki) Andrew Cattermole wrote:
> Yeah you didn't turn the warning on.

Thanks for pointing that out. That's one of the two problems with warnings.

The other problem is each C compiler has a different idea of warnings, and sometimes they are mutually contradictory. This makes porting code between compilers problematic with all warnings on, which led me (years ago) to give up on turning all warnings on.

This led to my original concept of D as having no warnings. We should probably revisit our current set of warnings and see if they can be made errors.

Thank you!

Looks like the C folk are looking at adding nullability qualifier to the language to merge the different compiler support.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3422.pdf

Related an effect system: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3317.htm

And if anyone is interested as to where you can find these documents: https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm