4 ms·

I used to program on a platform where you could have two pointers (say, integer pointers) that were not equal to each other, yet a store to one would change the

by spc476 5y ago

I used to program on a platform where you could have two pointers (say, integer pointers) that were not equal to each other, yet a store to one would change the location pointed to by the other pointer. Hint: it was a very popular architecture in the 80s and 90s. Spoiler: The 8088. I'm not saying I want to go back to that era (yes, I do like flat address spaces) but even on modern systems today it's possible to map memory such that two different pointers point to the same physical memory (but yes, you have to go out of your way to do that these days). If I could, I would disallow integer to pointer---there are (in my opinion) better ways to address a hardware register than to do unsigned char *uart = (unsigned char *)0xdeadbeef; /* [1] */ But I don't think it will go away any time soon in C (Over 30+ years later, and we're still a few years out from 1's compliment and signed magnitude integers being deprecated). [1] Here's one way using NASM: global uart absolute 0xdeadbeef uart resb 1 Then in C code: extern unsigned char uart;

xscott 5y ago
> I used to program on a platform [...] Yeah, and I know that's why the C standard has so much slop in it. They want to keep the window of conformance open for past or future architectures. > If I could, I would disallow integer to pointer [...] It's not just about 0xDeadBeef hardware addresses, and I don't think anyone is talking about breaking assembly language. However, C has unions and Rust has enums. You want those to share the same piece of memory in the fewest bytes you can get away with. Some interpreters, written in C, even use nan-tagging to store the important 48 bits of a pointer in the 52 bits of payload with double precision floats. You don't have to like it, and you can discourage your children or coworkers from doing it, but there are legitimate reasons for all of this. The examples look ugly because they're short and stupid. And nobody has even mentioned that `A[i] == (A + i) == (i + A) == i[A]` is going to continue to be valid in C. https://stackoverflow.com/a/381549 https://stackoverflow.com/a/381549

by spc476 5y ago

xscott 5y ago

> I used to program on a platform [...] Yeah, and I know that's why the C standard has so much slop in it. They want to keep the window of conformance open for past or future architectures. > If I could, I would disallow integer to pointer [...] It's not just about 0xDeadBeef hardware addresses, and I don't think anyone is talking about breaking assembly language. However, C has unions and Rust has enums. You want those to share the same piece of memory in the fewest bytes you can get away with. Some interpreters, written in C, even use nan-tagging to store the important 48 bits of a pointer in the 52 bits of payload with double precision floats. You don't have to like it, and you can discourage your children or coworkers from doing it, but there are legitimate reasons for all of this. The examples look ugly because they're short and stupid. And nobody has even mentioned that `A[i] == (A + i) == (i + A) == i[A]` is going to continue to be valid in C. https://stackoverflow.com/a/381549 https://stackoverflow.com/a/381549