incorrect/misleading error message for null pointer pointer arithmetic outside a valid region

[whyvn]

when attempting to perform pointer arithmetic on a null pointer dcc complains that its dereferencing a null pointer. valgrind and clang with ub and address sanitisers dont complain about this issue

mre:

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

Runtime error: accessing a value via a NULL pointer
dcc explanation: You are using a pointer which is NULL
  A common error is accessing *p when p == NULL.                                
                    
Execution stopped in main() in test.c at line 2:

int main(void) {
--> (void)((int *)0+0);
    return 0;   
}            
 
Don't understand?  Get AI-generated help by running: dcc-help, or interactive he
lp with dcc-sidekick         

even weirder, when the pointer is initialised to anything other than 0, this error doesnt occur even though its undefined behaviour to initialise to an aitrary non zero integer and its also still ub to perform pointer arithmetic on these values.
and even moree weirder, some types such as char * and void * dont trigger this error but it seems like any other type does

[Dylan-Brotherston]

UB-san does error on this code

$ clang-19.1.7 -std=c23 -fsanitize=undefined test.c
./a.out
test.c:2:18: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.c:2:18

What does the C standard say is valid pointer arithmetic:

If the pointer operand points to an element of an array object, and the
array is large enough, the result points to an element offset from the original element such that the
difference of the subscripts of the resulting and original array elements equals the integer expression.
otherwise, the behavior is undefined

As a null pointer is not a pointer to an element of an array object this is UB.

Except that the newest draft of the next C standard states that:

The expression ptr + N (where ptr is a null pointer value) is defined to result in a null pointer value when N is zero and has undefined behavior otherwise.

which would make this case not UB.

and indeed with a new enough compiler

$ clang-21.1.0 -std=c2y -fsanitize=undefined test.c
./a.out

There is no error.

---

But you are correct that there is no deref going on here.

DCC is mis-attributing this issue as it basically just sees "null pointer" and "undefined-behavior" and assumes deref.

---

why does

  (void)((int *)1+0);

not give an error?

because of optimization.
clang sees that there are no side effects from this line of code, so it is simply optimized away and never evaluated.
one of the reasons that C compilers like UB is because they are allowed to optimized away UB
now should the compiler optimized away UB while we are sanitizing for UB, probably not.
and why is 0+0 not optimized in the same way? because it generated with a slightly different code structure and wasn't picked up by the optimizer.

---

and the same is try with

  (void)((char *)0+0);

different code generation leads to different optimization leads to the UB just not existing so there is nothing to execute.

A very thorough reading of the standard would likely find reasons why there is different code generation in these situations.

---

compiler explorer link showing all of this:
https://godbolt.org/z/csM63j8nn

[whyvn]

ah thank you for the explanation. also from what i found C23 N3220 6.3.1.8 seems to align with my previous understanding that its not ub until its dereferenced, its just implementation defined but there were alot of notes like "except as previously specified[, its not ub]" but since i havnt read the whole standard i guess i really cant say. but yea thank you.

so do you think this should be changed in dcc?