Re:A Provenance-aware Memory Object Model for C [pdf]
by dooglius on Saturday June 19, 2021 @04:22PM
(#27564093)
I would say that that transformation is legal, it doesn't even involve pointers. I don't think anything I said precludes escape analysis. How would provenance come into play here?
[ Parent
| on HN ]
Re:A Provenance-aware Memory Object Model for C [pdf]
by jcranmer on Saturday June 19, 2021 @07:07PM
(#27565373)
Suppose I invent bar as follows:
void bar() {
int y = 0;
int *py = &y;
uintptr_t scan = (uintptr_t)py;
while (1) {
scan ++;
char *p = (char*)scan;
if (p[0] == 5 && p[1] == 0 && p[2] == 0 && p[3] == 0) {
*(int*)p = 3;
break;
}
}
}
This code will scan the stack looking for an int whose value is 5 and replacing it with 3. It's only undefined behavior if there's some notion of provenance: there's no pointer arithmetic, it only happens without pointers. There's not even a strict aliasing violation (since char can read anything). And yet, this code is capable of changing the value of x in foo to 3.> I don't think anything I said precludes escape analysis. How would provenance come into play here?
Escape analysis is a form of pointer provenance.
Re:A Provenance-aware Memory Object Model for C [pdf]
by jcelerier on Saturday June 19, 2021 @06:03PM
(#27564906)
> I would say that that transformation is legal, it doesn't even involve pointers.
you don't know that void b() isn't implemented as
void b() {
int* ptr = make_a_valid_pointer_from_an_integer(1638541351);
*ptr = 10;
}
with 1638541351 sometimes being the address of x above ?
Re:A Provenance-aware Memory Object Model for C [pdf]
by lerno on Saturday June 19, 2021 @07:14PM
(#27565416)
Could another approach be taken, where local variables are considered implicitly “register”? In that case this simple example has no problem whatsoever. It does arise unnecessarily if the address of a local is taken but does not escape, but that ought to be rare.