I'm more talking about things like use of dead stack slots and to a much lesser extent, use of uninitialized storage
-
-
since probably >95% of code suffers a negligible performance penalty if you just zero all allocations
4 replies 0 retweets 0 likes -
Replying to @johnregehr @samth
Sounds like you’re saying that this is another UB that is trivial to fix by just specifying that variables get zero-initialized.
1 reply 0 retweets 1 like -
for most code, yes, but as Sam said it's the UAFs and OOBs that are hard to define sensibly without changing the language too much
1 reply 0 retweets 0 likes -
Replying to @johnregehr @samth
OOB and UAF means you write to some other object or trap. Seems easy to specify to me.
2 replies 0 retweets 0 likes -
I guess I don't understand this conversation. you only want to solve the problems that are easy to solve?
1 reply 0 retweets 1 like -
specifying OOBs as doing random stuff is not effectively different from UB
1 reply 0 retweets 2 likes -
Replying to @johnregehr @samth
Doing random stuff and writing to a random object are different statements. The latter does not permit demons in the nose.
1 reply 0 retweets 0 likes -
Replying to @filpizlo @johnregehr
It has to be allowed to write to - the stack - anywhere in the heap - out of bounds triggering a segfault - whatever embedded devices do - probably other stuff too
4 replies 0 retweets 1 like -
Let’s go even further: UB has to be allowed to write to the current instruction pointer if W^X is not enabled. So literally anything can happen. :)
4 replies 2 retweets 3 likes
Text is never mapped writable on any modern system. W^X is a stronger property, means system completely disallows creation of W+X memory.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.