4 ms·
And `unsigned long` can store pointers just fine on Linux 32, Linux 64, Windows x86-32, and MSYS2 64... but not Windows x86-64. https://github.com/cc65/cc65/iss
by nyanpasu64 5y ago
And `unsigned long` can store pointers just fine on Linux 32, Linux 64, Windows x86-32, and MSYS2 64... but not Windows x86-64. https://github.com/cc65/cc65/issues/1680#issuecomment-1046412397 https://github.com/cc65/cc65/issues/1680#issuecomment-104641...
- loeg 5y ago32-bit 'long' on a 64-bit pointer platform is kind of a bizarre choice by Microsoft. Technically allowed by the C abstract machine, of course.
- bombcar 5y agoArguably on a system where you can address 8 bit byte, 16 bit word, 32 bit dword, and 64 bit qword having char, int, long, and long long all be different sizes makes sense (and gives the programmer control) - especially if before they were assumed to be shorter. A program with 32bit longs will probably work fine most of the time, and save memory while doing it (which can matter for cache hits/misses).
- leetcrew 5y agoint is the same width as long in msvc though. if the width of an integral type is remotely important to the correctness of your program, you should really be using stdint.h types to document that intention, regardless of whether you care about portability.
- loeg 5y agoint on Win64 is 32 bit, not 16.
- andrewf 5y agoA lot of early Win32 code was originally Win16 code - you could in theory have the same code target both. I think that encouraged everyone to favor long / DWORD when they wanted a 32-bit integer even once the 16-bit compilers were receding into the distance.
- kevin_thibedeau 5y agoThey screwed up by letting LONG into their OS structs when DWORD should have been good enough. It would be a huge clusterfuck if long was 64-bit while LONG stayed 32-bit.