3 ms·
The problem is backward compatibility with external linking because this expects another word on the call stack. It also relies on the programmer to be smart ab
by jl2718 6y ago
The problem is backward compatibility with external linking because this expects another word on the call stack. It also relies on the programmer to be smart about bounds, which, they’re already intentionally ignoring, so, I don’t know. However, there are some attempts at a hardware solution to provide memory safety without modifying the stack: https://en.m.wikipedia.org/wiki/Intel_MPX https://en.m.wikipedia.org/wiki/Intel_MPX. At array creation time, the pointer bounds are loaded into a register and the address is translated between a safe address and a real address. I don’t actually know if this works in a transparent backward-compatible way, as in, ignoring unregistered pointers and translating without being told to. I should also mention that AddressSanitizer also does something similar in software, and is becoming ubiquitous. The performance/size penalties are significant, bu it seems to me that the hardware translation should be fast if it is separately integrated with the existing cache address translation and memory bus.
- WalterBright 6y ago> The problem is backward compatibility with external linking because this expects another word on the call stack. It's completely compatible if you use the [..] syntax. > performance/size penalties For the proposed scheme, they are essentially non-existent. This is because the array bounds is usually already being passed as a separate argument. Arrays that rely on a sentinel to determine the end (like 0-terminated strings) one can just not use the new syntax.