better codegen of undefined

[PavelVozenilek]

Variable in Zig can be left uninitialized by undefined.

It would be handy if there was compiler command line option/project config file settings to override this and make all undefined variables initialized with their default.

If the application was behaving unpredictably before and after forced initialization it looks OK one knows the cause.

This is a feature in Jai language.

[thejoshwolfe]

In safety mode, initializing to undefined is actually a memset to 0xaa. This is to make it easier to notice if you're using undefined values in a debugger.

This is different from what you're proposing, which is memset to 0, but i think it has the same effect or better.

The value 0xaa was chosen because it is recognizable by a human, not likely to appear by chance in actual undefined values, and not likely to cause apparently correct behavior if you accidentally use it. Using 0 does not have these benefits.

Zig tries very hard to prevent undefined behavior, and helping you find where your code is reading uninitialized memory is part of that goal. If your code actually uses undefined values, it is unquestionably a bug. We don't want the compiler to enable that bug to go unnoticed by setting uninitialized memory to 0.

Of course this isn't a perfect solution. Valgrind can give much more sophisticated diagnostics than 0xaa, but the question is: what value should safety mode use for undefined? 0xaa is better for catching bugs than 0, and catching bugs is more important than making code appear to work with undefined behavior.

[andrewrk]

I'm going to re-open this issue for a couple reasons:

• Fix the regression with setting undefined variables to 0xaa with the IR branch merge
• also set to 0xaa if you assign something to undefined somewhere other than the declaration
• we don't set global variables to 0xaa because it's kind of awkward to do this in the LLVM API, even though it's really easy to do in ELF in debug builds, global variables which are undefined should be initialized with 0xaa #1987
• we need to send a patch to LLVM to have it emit global variables which are initialized to undefined to .bss. right now it bloats object file size. this would be for release modes of zig send patch to LLVM to make it emit globals which are undefined into .bss #1988
• we don't have a way to communicate to tools like valgrind that a variable set to 0xaa is actually undefined. it might make sense to have a command line switch as suggested to allow these tools to work correctly - by actually leaving undefined things undefined. ideally there would be some kind of DWARF tag that valgrind could read and make that conclusion automatically. but that requires coordination of a lot of open source projects. improve valgrind client request support to include more targets #1989

[PavelVozenilek]

Assigning always the same fixed value to undefined will hide potential errors. Something random (and nonzero) would be better to spot problem before it gets into release.

[andrewrk]

I agree with this statement. However this introduces non reproducible builds, which is something to discuss before causing to happen.

[thejoshwolfe]

Randomness can be reproducible if it's externally seeded. The command line option to enable undefined value randomization can take a seed, then the builds are always a deterministic function of their inputs.

[PavelVozenilek]

> introduces non reproducible builds

Compiler initializes random generator (e.g. xoroshiro128 - http://vigna.di.unimi.it/xorshift/xoroshiro128plus.c ) from current time at the start and then inserts initialization memcpy after variable declaration. No hardcoded random numbers in executable.

The generator could always set the highest bit to 1, to make the number large or negative, to increase probability of undesirable effects.

Forcing "everything defined" would simply use value 0 instead of the generator. Specifying the seed on command line would be too much hassle and it wouldn't speed up bug discovery.

[andrewrk]

I think there's value in 0xaa. The pattern is very noticeable in both hex and binary, and it's also a large or negative number. It's likely nothing will be mapped to address 0xaaaaaaaaaaaaaaaa.

If we do want to use a random seed and achieve reproducible builds, we can't seed based on time. But we could seed based on seemingly random things such as number of characters in all the source code combined.

[PavelVozenilek]

If 0xaa is/will be the default then there's no point in my proposal - it is already here.

Under the term "reproducible build" I understand generated binary being always the same on the disk, byte for byte, not actual execution always following the same path.

If my understanding is correct source of the seed doesn't matter.

[andrewrk]

We can use valgrind's client request mechanism to not set undefined bytes to 0xaa when RUNNING_ON_VALGRIND is true.
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq

it still doesn't solve assigning undefined later, but I sent a request to the valgrind mailing list asking about it.

[andrewrk]

quick response.
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs
VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DEFINED.

we can have our cake and eat it too.

[andrewrk]

I moved all the issues mentioned in #460 (comment) to their own issues.