Fix uninit read benchmark

[ThomasHaas]

This fixes the uninitRead.c benchmark to work independent of the RemoveUnusedMemory pass and adds a clarifying warning that this test is about accessing uninitialized memory and not initialized memory via overflows (we do not handle the latter correctly).

[ThomasHaas]

Hmm, maybe it is better to have a malloc and read from the malloc`d memory without initialization. That might be more principled.

[hernanponcedeleon]

Hmm, maybe it is better to have a malloc and read from the malloc`d memory without initialization. That might be more principled.

Yes, I like this test rather than having that magic number constant in the array access

[ThomasHaas]

I changed the test. Now it doesn't distinguish between the previous Dartagnan version and the new one though.

[hernanponcedeleon]

I think there are two scenarios around the issue we discussed

• accessing allocated, but uninitiated memory
• accessing out-of-bound memory (independently if it was properly initialized by the allocator)

My understanding is that we properly handle (and did this before #624) the former and the benchmark in this PR shows this.

However, we do not properly handle the second situation (sometimes we do "by luck"). There are several things that influence this (e.g. does the address of the out-of-bound access matches the address or another object, are we using Caat or the eager encoding), but the culprit is that our alias analyses are unsound (by design) in the presence of out-of-bound accesses.

Since we only fully support one of the scenarios, it makes sense to me that the benchmark is about that one.

[ThomasHaas]

Since we only fully support one of the scenarios, it makes sense to me that the benchmark is about that one.

Yes, it makes sense.

• accessing allocated, but uninitiated memory
• ...

My understanding is that we properly handle (and did this before #624) the former and the benchmark in this PR shows this.

We did handle the former only because we created init events. If we had not created them (as we do for out-of-bounds memory) we would have erroneously returned PASS. Now we also handle it without creating init events. It's just that the test cannot distinguish "old version + inits" vs. "new version + no inits". It distinguishes from "old version + no inits" but that combination only happened on out-of-bounds memory accesses and that's why I had it initially like this.

Either way, it's still a simple and valid test.