4 ms·

>> in certain circles there is this weird fetishitization of portability, placing it on the highest pedestal as a metric of quality. It's not a fetish if you h

>> in certain circles there is this weird fetishitization of portability, placing it on the highest pedestal as a metric of quality. It's not a fetish if you have ever ported legacy code that was not written with potability in mind. "ints are always 32-bit and can be used to store pointers with a simple cast" may have worked when the legacy program was written, but it sure makes porting it a pain.

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 ago
  32-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 ago
    Arguably 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 ago
      int 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 ago
      int on Win64 is 32 bit, not 16.
  - andrewf 5y ago
    A 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 ago
    They 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.
compiler-guy 5y ago
This is absolutely true, but doesn’t make the case that the original authors should have compromised their design or spent the extra effort to make the code portable. If the spec was to make it work under certain conditions and not to worry about others, then the additional work for portability just adds cost.
scaramanga 5y ago
The question is how much time is spent maintaining and testing for correctness a portable program in it's early iteration vs the time spent porting it for it's second lease of life. Clearly if it it would have cost 2N dollars to obviate N dollars of work, then cost would not have been worth it. This can occur if either a) portability complicates things a lot or b) it complicates things a little, but over a very long timespan during which maintenance work is being done.
jart 5y ago
It should work today. If we migrate to ILP64 data model then we can restore many of those elegant behaviors, because it makes C so easy, almost like a scripting language. As far as I can tell, the original motivations for the LP64 data model which causes int and int* to be different widths, was because SCO wanted it that way. They never published the measurements that led them to this conclusion. Are you willing to sacrifice language simplicity based on the word of the people who are famous for suing Linux users?
- joosters 5y ago
  The Open Group's study into LP64/ILP64 explains their choice fairly well. In particular, it mentions both Digital and SGI's prior experience with porting code to LP64. There's nothing about SCO's preferences in it. http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm "By far, the largest body of existing code already modified for 64-bit environments runs on LP64 based platforms."
DrScump 5y ago
>It's not a fetish if you have ever ported legacy code that was not written with portability in mind. This. You can code portably and take advantage of platform-specific features or performance advantages. I used to work on a product line that supported dozens of different UNIX platforms (and, eventually, even DOS protected-mode). The entire build process was portable. We had a primary configuration file for code/libraries and one for server internals that provided for: . shared memory configuration (if any) and other limits . BSD sockets vs System V streams . byte-swapped vs regular processors and little- vs big-endian . 16- vs 32-bit processors (later 64 bit) . RISC vs CISC . vagaries of C compilers, normal flags to pass for optimization, gcc vs cc, static vs dynamic links, libraries etc . INT / LONG bytecounts, floating point, etc. . ... and many others. The goal was to abstract everything possible and have platform-specific code limited to the configuration files. Then, porting becomes fine tuning the configuration files, adding platform specific code to the mainline (with appropriate DEFINES) only when absolutely necessary, test, finalize configuration, test again, post the final config files and any changes back to the mainline.

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 ago
32-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 ago
  Arguably 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 ago
    int 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 ago
    int on Win64 is 32 bit, not 16.
- andrewf 5y ago
  A 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 ago
  They 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.

compiler-guy 5y ago

This is absolutely true, but doesn’t make the case that the original authors should have compromised their design or spent the extra effort to make the code portable. If the spec was to make it work under certain conditions and not to worry about others, then the additional work for portability just adds cost.

scaramanga 5y ago

The question is how much time is spent maintaining and testing for correctness a portable program in it's early iteration vs the time spent porting it for it's second lease of life. Clearly if it it would have cost 2N dollars to obviate N dollars of work, then cost would not have been worth it. This can occur if either a) portability complicates things a lot or b) it complicates things a little, but over a very long timespan during which maintenance work is being done.

jart 5y ago

It should work today. If we migrate to ILP64 data model then we can restore many of those elegant behaviors, because it makes C so easy, almost like a scripting language. As far as I can tell, the original motivations for the LP64 data model which causes int and int* to be different widths, was because SCO wanted it that way. They never published the measurements that led them to this conclusion. Are you willing to sacrifice language simplicity based on the word of the people who are famous for suing Linux users?

joosters 5y ago
The Open Group's study into LP64/ILP64 explains their choice fairly well. In particular, it mentions both Digital and SGI's prior experience with porting code to LP64. There's nothing about SCO's preferences in it. http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm "By far, the largest body of existing code already modified for 64-bit environments runs on LP64 based platforms."

DrScump 5y ago

>It's not a fetish if you have ever ported legacy code that was not written with portability in mind. This. You can code portably and take advantage of platform-specific features or performance advantages. I used to work on a product line that supported dozens of different UNIX platforms (and, eventually, even DOS protected-mode). The entire build process was portable. We had a primary configuration file for code/libraries and one for server internals that provided for: . shared memory configuration (if any) and other limits . BSD sockets vs System V streams . byte-swapped vs regular processors and little- vs big-endian . 16- vs 32-bit processors (later 64 bit) . RISC vs CISC . vagaries of C compilers, normal flags to pass for optimization, gcc vs cc, static vs dynamic links, libraries etc . INT / LONG bytecounts, floating point, etc. . ... and many others. The goal was to abstract everything possible and have platform-specific code limited to the configuration files. Then, porting becomes fine tuning the configuration files, adding platform specific code to the mainline (with appropriate DEFINES) only when absolutely necessary, test, finalize configuration, test again, post the final config files and any changes back to the mainline.