Pointers Are Complicated, or What’s in a Byte?

Re:Pointers Are Complicated, or What’s in a Byte? by gmueckl on Wednesday July 25, 2018 @05:08AM (#17607868)

This cannot possibly be correct. A read access to a region without a mapped page in the page table will cause the CPU to trigger a page fault exception. The OS must then decide whether to map memory there a one time operation or abort the program. A second read from the same page must lead to the same mapping then. There is no sane way for an operating system to switch out program heap pages after they have been mapped.

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by ralfjung on Wednesday July 25, 2018 @07:02AM (#17608321)

This is looking at the wrong level of abstraction though. The compiler will already optimize your code in a way that multiple uses of the same uninitialized value can produce different results.

Arguing about these assembly/CPU-level details (unfortunately?) is besides the point when debating the semantics of languages like C, C++ or Rust.

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by gmueckl on Wednesday July 25, 2018 @07:32AM (#17608440)

Grandparent already narrowed discussion down to x86 behaviour and I responded to details on that. This is definitely all outside the scope of language specifications.

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by vardump on Wednesday July 25, 2018 @05:20AM (#17607924)

I read "memory is untouched" as no read/write accesses.

Because it'd be pretty odd for the page to change after first read from operating system implementation point of view. Generally I'd expect the default mapping to be to an all-zero physical memory page. (Unless there's a rowhammer attack (or similar) that successfully modifies said all-zero page...)

From C/C++ point of view, it's legal for uninitialized memory to arbitrarily change between (undefined behavior) reads until it is written to.

While I doubt any actual OS would modify the page in this manner after first read access, a C/C++ compiler can still return arbitrary (even random) values when reading from uninitialized memory. It doesn't even need to actually read from the memory proven to be uninitialized.

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by gpderetta on Wednesday July 25, 2018 @06:34AM (#17608217)

madvise MADV_DONTNEED

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by GolDDranks on Wednesday July 25, 2018 @07:11AM (#17608367)

I'm not going to take the responsibility whether it's correct or not - here's the talk I learned it from: https://youtu.be/kPR8h4-qZdk?t=22m17s

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by gmueckl on Wednesday July 25, 2018 @07:57AM (#17608569)

I haven't watched all of it, but the explanation for the null terminator bug must contain some OS interaction telling the kernel that it is actually safe to discard the page containing the null terminator (e.g. the madvice call mentioned in a sibling post). If you're doing things like that, you're asking for trouble.

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by _pmf_ on Wednesday July 25, 2018 @05:54AM (#17608071)

> There is no sane way for an operating system to switch out program heap pages after they have been mapped.

They'll even move the page to the harddisk if necessary. Or am I misunderstanding what you're asking?

[ Parent | on HN ]

Re:Pointers Are Complicated, or What’s in a Byte? by gmueckl on Wednesday July 25, 2018 @07:28AM (#17608430)

The OS can move the content of the pages in physical memory, but it will not make the page table entry point to a page with different content after that point.

[ Parent | on HN ]