4 ms·

I know what the post is trying to say and all the examples are fine and learning C(++) you should be aware of this and everything, but I think the conclusion of

I know what the post is trying to say and all the examples are fine and learning C(++) you should be aware of this and everything, but I think the conclusion of saying that this shows pointers aren't integers is an odd choice. They still are in memory. It's all about the interpretation of these integers, and the shortcuts compilers can take because the standard allows them to do so, as the author points out. If you turn off all optimizations or go ahead and write a really simple compiler yourself, you probably end up getting exactly the results you'd "expect" from those examples, at least on any platform that is not totally exotic. Also uninitialized bytes are still ordinary bytes, you just get a free rand() run. :) Yeah maybe it's just me being weird.

vardump 8y ago
Pointers are not integers in abstract model C++ compilers use for reasoning about code. This is all about the abstract model used for optimization according to the language specification.
- iforgotpassword 8y ago
  Sure, I thought I made that clear in my post. Also I didn't want to imply that this is good code or code anyone should write. However I still think when learning C or explaining the language it is vastly helpful to go with the analogy of pointers being integers, since it is so much easier to grasp. Which doesn't mean that shouldn't come with a big warning not to write weird unsafe code and everything; but even if the standard would actually mandate that any form if crazy pointer arithmetic would be defined behavior I wouldn't exactly encourage anyone to write code like that.
  - ralfjung 8y ago
    The sad truth is that I have seen, several times, people justifying real code doing questionable things with pointers in C(-like languages) by saying "well but pointers are just integers". I am not sure what the best way to teach C is. Maybe it is a good idea to start with a "lie" and explain pointers as integers. But most C books/tutorials never go to the part where they explain that this is a lie, and that is a problem. The problem will only get worse as compilers get smarter and hence better at exploiting the UB that lurks in so many programs due to a naive treatment of pointers.
- IshKebab 8y ago
  There should be a different word for that though. A pointer is literally a stored memory address, i.e. an integer. The thing the compiler manipulates could be called a "C pointer" or something.
  - vardump 8y ago
    > A pointer is literally a stored memory address, i.e. an integer. Consider: int a = 5; int* b = &a; What happens when 'a' is allocated to a CPU register? If 'b' never escapes and no (undefined) pointer arithmetic is used, the compiler can simply consider '*b' as an alias to 'a'. In this case the 'pointer' never actually points to memory. > The thing the compiler manipulates could be called a "C pointer" or something. Perhaps, although when talking about pointers, it's almost always in context of a particular programming language. Maybe it'd be better to talk about "hardware pointers". Although on hardware level, from CPU point of view, a value or a register generally only becomes a "pointer" when it's used to compute a memory address for an instruction that accesses memory. (Excluding special hardware registers, like instruction pointer, page tables, DMA hardware or interrupt/exception vectors.) So a "pointer" is always an abstraction in context of general purpose processing.
  - adwn 8y ago
    > A pointer is literally a stored memory address, i.e. an integer. This is not correct in general. In x86 real mode, addresses consist of a segment and an offset. The linear address is computed as segment * 16 + offset. This is very different from a single integer, and even somewhat different from a pair of integers: Two different segment/offset-pairs can refer to the same linear address, so a pointer comparison has to behave differently than an integer-pair comparison.
    - raverbashing 8y ago
      You're not wrong, but the segment/offset model is such a farce it's not even worth using as an example (also you would have had to distinguish between far and near pointers) At the processor level, pointers are distinguished either by the type of register or by the type of operation used on them (when they're more orthogonal, still there are "pointer only" registers like stack, ip, etc)
GolDDranks 8y ago
Unitialized bytes can NOT be considered "ordinary bytes" on x86. This is because of memory paging and copy-on-write. If a memory is untouched, it is allowed to map to a different physical memory on different accesses, so the contents are not only "unknown", they may change under your feet! You must touch the memory page for this not to happen.
- iforgotpassword 8y ago
  TIL, nice detail (Not that I would've recommended using uninitialized bytes as an RNG anyways ;))
- gmueckl 8y ago
  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.
  - _pmf_ 8y ago
    > 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?
    - gmueckl 8y ago
      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.
  - vardump 8y ago
    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.

vardump 8y ago

Pointers are not integers in abstract model C++ compilers use for reasoning about code. This is all about the abstract model used for optimization according to the language specification.

iforgotpassword 8y ago
Sure, I thought I made that clear in my post. Also I didn't want to imply that this is good code or code anyone should write. However I still think when learning C or explaining the language it is vastly helpful to go with the analogy of pointers being integers, since it is so much easier to grasp. Which doesn't mean that shouldn't come with a big warning not to write weird unsafe code and everything; but even if the standard would actually mandate that any form if crazy pointer arithmetic would be defined behavior I wouldn't exactly encourage anyone to write code like that.
- ralfjung 8y ago
  The sad truth is that I have seen, several times, people justifying real code doing questionable things with pointers in C(-like languages) by saying "well but pointers are just integers". I am not sure what the best way to teach C is. Maybe it is a good idea to start with a "lie" and explain pointers as integers. But most C books/tutorials never go to the part where they explain that this is a lie, and that is a problem. The problem will only get worse as compilers get smarter and hence better at exploiting the UB that lurks in so many programs due to a naive treatment of pointers.
IshKebab 8y ago
There should be a different word for that though. A pointer is literally a stored memory address, i.e. an integer. The thing the compiler manipulates could be called a "C pointer" or something.
- vardump 8y ago
  > A pointer is literally a stored memory address, i.e. an integer. Consider: int a = 5; int* b = &a; What happens when 'a' is allocated to a CPU register? If 'b' never escapes and no (undefined) pointer arithmetic is used, the compiler can simply consider '*b' as an alias to 'a'. In this case the 'pointer' never actually points to memory. > The thing the compiler manipulates could be called a "C pointer" or something. Perhaps, although when talking about pointers, it's almost always in context of a particular programming language. Maybe it'd be better to talk about "hardware pointers". Although on hardware level, from CPU point of view, a value or a register generally only becomes a "pointer" when it's used to compute a memory address for an instruction that accesses memory. (Excluding special hardware registers, like instruction pointer, page tables, DMA hardware or interrupt/exception vectors.) So a "pointer" is always an abstraction in context of general purpose processing.
- adwn 8y ago
  > A pointer is literally a stored memory address, i.e. an integer. This is not correct in general. In x86 real mode, addresses consist of a segment and an offset. The linear address is computed as segment * 16 + offset. This is very different from a single integer, and even somewhat different from a pair of integers: Two different segment/offset-pairs can refer to the same linear address, so a pointer comparison has to behave differently than an integer-pair comparison.
  - raverbashing 8y ago
    You're not wrong, but the segment/offset model is such a farce it's not even worth using as an example (also you would have had to distinguish between far and near pointers) At the processor level, pointers are distinguished either by the type of register or by the type of operation used on them (when they're more orthogonal, still there are "pointer only" registers like stack, ip, etc)

GolDDranks 8y ago

Unitialized bytes can NOT be considered "ordinary bytes" on x86. This is because of memory paging and copy-on-write. If a memory is untouched, it is allowed to map to a different physical memory on different accesses, so the contents are not only "unknown", they may change under your feet! You must touch the memory page for this not to happen.

iforgotpassword 8y ago
TIL, nice detail (Not that I would've recommended using uninitialized bytes as an RNG anyways ;))
gmueckl 8y ago
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.
- _pmf_ 8y ago
  > 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?
  - gmueckl 8y ago
    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.
- vardump 8y ago
  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.