> 6. EXAMPLE Code that checks to see if a pointer value is null cannot be omitted during translation solely on the basis that the pointer is dereferenced before the check and that earlier dereference would produce undefined behavior if the pointer value was null.

Here's the thing I don't quite understand: I gather that this is advocating for something like GCC's -fno-delete-null-pointer-checks to be part of the spec, but, how is -fno-delete-null-pointer-checks actually helpful?

I think it's because if you write code like this:

    void foo(struct foo *param) {
        int n = param->length, i;
    
        if (param == NULL) {
            return;
        }
    
        for (i = 0; i < n; i++) {
            do_something(param->data[i]);
        }
    }

with -fdelete-null-pointer-checks the compiler might optimize it in two successive steps to delete the check (because param->length was already dereferenced) and then move the dereference down to the beginning of the for loop, and with -fno-delete-null-pointer-checks the compiler might skip the first optimization and keep the second.

But for -fno-delete-null-pointer-checks, you're relying on the second optimization, moving the dereference later. Otherwise you'd just have segfaulted already (or, in a kernel context, the read might have succeeded from a userspace page mapped at the null page). Right?

It seems reasonable for the compiler (or some other tool) to produce a hard error here and prevent this code from compiling, saying, hey, this is clearly doing something unwanted. It doesn't seem reasonable to expect the compiler to do certain optimizations to make your code safe, without which your code would have a security vulnerability, and also get mad at the compiler for doing more optimizations that return it to the original state of things.

> The limitation of lvalue access by types has never made much sense and required a undefensible exception for character pointers.

My understanding of type-based alias analysis is that it's required for code like this to optimize the way you'd want:

    struct string {
        size_t len;
        char *data;
    }

    void copy_string(struct string *dest, struct string *src) {
        size_t i;
        if (dest->len < src->len) return;
        for (i = 0; i < src->len; i++) {
            dest->data[i] = src->data[i];
        }
    }

Otherwise the compiler would have to worry that dest->data would overlap with src->len and re-read it every time!

You can do this without type-based alias analysis in a language that gave you different tools for managing variables, but doing so backwards-compatibly in C seems difficult, and this proposed rule does not seem to help.