5 ms·
More information on this behavior in the link below. > Note that, apart from contrived examples with deleted null checks, the current rules do not actually hel
by david-gpu 2y ago
More information on this behavior in the link below.
> Note that, apart from contrived examples with deleted null checks, the current rules do not actually help the compiler meaningfully optimize code. A memcpy implementation cannot rely on pointer validity to speculatively read because, even though memcpy(NULL, NULL, 0) is undefined, slices at the end of a buffer are fine. [And if the end of the buffer] were at the end of a page with nothing allocated afterwards, a speculative read from memcpy would break
https://davidben.net/2024/01/15/empty-slices.html https://davidben.net/2024/01/15/empty-slices.html
- Someone 2y ago> [And if the end of the buffer] were at the end of a page with nothing allocated afterwards, a speculative read from memcpy would break ‘Only’ on platforms that have memory protection hardware. Even there, the platform can always allocate an overflow page for a process, or have the page fault handler check whether the page fault happened due to a speculative read, and repair things (I think the latter is hugely, hugely, hugely impractical, but the standard cannot rule it out)
- immibis 2y agoPlatforms without memory protection hardware also have no problem reading NULL.
- Someone 2y agoMy comment is a reply to (part of) a comment that isn’t talking about reading from NULL. That’s what the [And if the end of the buffer] part implies. Even if it didn’t, I don’t think the standard should assume that “Platforms without memory protection hardware also have no problem reading NULL” An OS could, for example, have a very simple memory protection feature where the bottom half of the memory address range is reserved for the OS, the top half for user processes, and any read from an address with the high bit clear by code in the top half of the address range traps and makes the OS kill the process doing the read.
- BenjiWiebe 2y agoDoesn't it take memory protection hardware to trap on a memory read?
- lmm 2y agoAs a philosophical matter, by definition that would be memory protection hardware, sure. But the point is that it's at least conceivable that some platforms might have some crude, hardwired memory protection without having a full MMU.
- hun3 2y agoNot really. MMIO mapped at 0x0 for example.
- david-gpu 2y agoYikes! I would love sipping coffee watching the chief architect chew up whoever suggested that. That sounds awful even on a microcontroller.
- bonzini 2y agoOn s390 the memory at address 0 (low core) has all sorts of important stuff. Of course s390 has paging enabled pretty much always but still...
- colejohnson66 2y agoAVR’s registers are mapped to address 0. So reading and writing NULL is actually modifying r0.
- formerly_proven 2y agoAVR’s r0 is also a totally normal register, unlike most other RISC which typically have r0 == 0.
- david-gpu 2y agoThanks for saving me a search, because I was expecting r0 to be hardcoded to zero. Sometimes hardware is designed with insufficient input from software folks and the result is something asinine like that. That, or some people like watching the world burn.
- kevin_thibedeau 2y agoThey may also expect writes to address 0.
- Zondartul 2y agoWhat does "speculative" mean in this case? I understand it as CPU-level speculative execution a.k.a. branch mis-prediction, but that shouldn't have any real-world effects (or else we'd have segfaults all the time due to executing code that didn't really happen)
- dwattttt 2y agoTurns out you can have that kind of speculative failure too! https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/ https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-d...