4 ms·

upper 16 bits are usually unused on x86_64 as well (since the x86_64 virtual address space is only 48-bit), though whether they're one or zero depends on bit 48

by PeCaN 7y ago

xxs 7y ago
yeah, 64bit is a lot of address space, and masking/shifting provides quite a few bits if one is willing to manage their own pointers.
- rocqua 7y ago
  Hard to get this done properly in C I imagine. You're getting into UB the moment you start bit-fiddling with pointers I think.
  - PeCaN 7y ago
    Nah, so long as you cast to an integer (preferably uintptr_t) before fiddling with it you're fine¹ ― ¹ I think, but to be honest it's been some time since I really knew the arcane C rules and I'm not confident anymore
  - vnorilo 7y ago
    Not UB but rather implementation defined. The compiler will not do anything weird here, but you rely on platform behavior that's not specified by the C lang spec.
  - Asooka 7y ago
    Not UB in the slightest. You can take a pointer, cast it to uintptr_t, do whatever you want to that int, then cast it back to a pointer. It's only UB if the resulting pointer isn't valid or you cast it to the wrong type (and strict aliasing is enabled.
    - rocqua 7y ago
      Hm, good to know.
msla 7y ago
This reminds me of all the problems Apple had with 24 bit addressing and smuggling data in the unused eight bits at the top of each pointer. Andy Hertzfeld considers that his worst blunder: http://www.folklore.org/StoryView.py?project=Macintosh&story=Mea_Culpa.txt http://www.folklore.org/StoryView.py?project=Macintosh&story...
rrobukef 7y ago
And doubles have some 2^50 NaN's. It's possible to create a tagged pointer of either a double, 32-bit integer, pointer or a small string and still have space for more. Sadly the original Mozilla link is broken. https://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations https://wingolog.org/archives/2011/05/18/value-representatio...

upper 16 bits are usually unused on x86_64 as well (since the x86_64 virtual address space is only 48-bit), though whether they're one or zero depends on bit 48

by PeCaN 7y ago

upper 16 bits are usually unused on x86_64 as well (since the x86_64 virtual address space is only 48-bit), though whether they're one or zero depends on bit 48

xxs 7y ago

yeah, 64bit is a lot of address space, and masking/shifting provides quite a few bits if one is willing to manage their own pointers.

rocqua 7y ago
Hard to get this done properly in C I imagine. You're getting into UB the moment you start bit-fiddling with pointers I think.
- PeCaN 7y ago
  Nah, so long as you cast to an integer (preferably uintptr_t) before fiddling with it you're fine¹ ― ¹ I think, but to be honest it's been some time since I really knew the arcane C rules and I'm not confident anymore
- vnorilo 7y ago
  Not UB but rather implementation defined. The compiler will not do anything weird here, but you rely on platform behavior that's not specified by the C lang spec.
- Asooka 7y ago
  Not UB in the slightest. You can take a pointer, cast it to uintptr_t, do whatever you want to that int, then cast it back to a pointer. It's only UB if the resulting pointer isn't valid or you cast it to the wrong type (and strict aliasing is enabled.
  - rocqua 7y ago
    Hm, good to know.

msla 7y ago

This reminds me of all the problems Apple had with 24 bit addressing and smuggling data in the unused eight bits at the top of each pointer. Andy Hertzfeld considers that his worst blunder: http://www.folklore.org/StoryView.py?project=Macintosh&story=Mea_Culpa.txt http://www.folklore.org/StoryView.py?project=Macintosh&story...

rrobukef 7y ago

And doubles have some 2^50 NaN's. It's possible to create a tagged pointer of either a double, 32-bit integer, pointer or a small string and still have space for more. Sadly the original Mozilla link is broken. https://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations https://wingolog.org/archives/2011/05/18/value-representatio...