Default null initialization of `REFERENCE TO` variables

[volsa]

we are auto-dereferencing an uninitialized pointer here - this is undefined behaviour. Should we initialize these pointers with null like we are doing for VAR_INPUT {ref}? Ideally we would check for use before assignment but that feature feels a bit far off still.

Originally posted by @mhasel in #1251 (comment)

I think null makes sense here so that we don't have random values. I'm in favour of not having such tests tbh. We can't test undefined behaviour (by design). Also what happens if the random value is 5? I am more in favour of having a test that verifies the pointer value of foo is null. Not sure how to do this with the auto deref rules.. maybe it's enough to have an IR check that verifies the initial values of REFERENCE TO and Pointer fields in general.

Originally posted by @ghaith in #1251 (comment)

[volsa]

As it turns out, (REFERENCE TO) pointers are by default NULL initialized. For example generating IR of the ST code in the linked comments yields

define i32 @main() section "fn-$RUSTY$main:i32" {
entry:
  %main = alloca i32, align 4
  %foo = alloca i32*, align 8
  %bar = alloca i32*, align 8
  %qux = alloca i32, align 4
  store i32* null, i32** %foo, align 8 ; null initialized
  store i32* null, i32** %bar, align 8 ; null initialized
  ; ...
 %deref = load i32*, i32** %bar, align 8 ; null pointer deref

Whats confusing though is that NULL initialized pointers do not segfault when dereferencing them in -Odefault compiled binaries. For example take the following code

FUNCTION main : DINT
    VAR
        foo : REF_TO DINT;
        bar : DINT;
    END_VAR

    foo^ := bar; // NULL pointer deref, should segfault
END_FUNCTION

Running with -Odefault does not segfault, running with -Onone does however. That's kinda troublesome, mainly because the default optimization level doesn't segfault when it probably should. I'm wondering if LLVM is optimizing away the NULL pointer deref?