5 ms·

Windows is an LLP64 platform, meaning that the "long" type on Windows stays at 32bit even when you're compiling 64bit binaries. Getting 64bit integer support fo

by nikic 9y ago

Windows is an LLP64 platform, meaning that the "long" type on Windows stays at 32bit even when you're compiling 64bit binaries. Getting 64bit integer support for PHP on Windows took a major port of all basic type usage to move away from longs to custom types with a higher degree of control. I don't know whether or not this was a problem for Firefox or not.

khuey 9y ago
This particular problem was never really an issue for Mozilla, because the codebase has used fixed width types (first the NSPR types and later the stdint.h types) for 20 years.
user5994461 9y ago
To clarify: When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. The other compilers vary. The C standard only specifies that int has to be at least 32 bits. That's one of the many issues of porting from 32 to 64 bits.
- syncsynchalt 9y ago
  Sorry to nitpick, but the C standard specifies that int must be at least 16 bits, and that long is at least 32 bits. (Actually, it just specifies the minimum range, and tries not to be specific as to the bit representation). https://en.wikipedia.org/wiki/C_data_types https://en.wikipedia.org/wiki/C_data_types
  - user5994461 9y ago
    Typo. I meant to write long, not int ^^
- deleted 9y ago
  [deleted]
- cygx 9y ago
  When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. That's not true for MinGW, and for good reasons (deviating from the ABI followed by the OS and all libraries would be stupid).
zeptomu 9y ago
If you think about it, I think its a little bit a fault of the language (AFAIK the C specification) defining basic integer types too loose. What is the advantage of having "int", "long" types that just give minimum byte requirements (with associated storage classes, etc.) instead of more specified types like int32_t and uint8_t? In the end you deal with fixed-size integers or not (using some bignum library), but if you deal with them you have to take their byte length into acount in your code anyway I would say (to deal with overflows and stuff).
- deleted 9y ago
  [deleted]
- nnethercote 9y ago
  I think the minimum sizes were chosen because of a combination of (a) there was a much greater variety of hardware available then, and (b) people hadn't learned that fixing these sizes is better.
- mjevans 9y ago
  They were that flexible because you'd compile ONE program ONCE for (any ported) platform and that was that. It took a little while, but eventually C got https://en.wikibooks.org/wiki/C_Programming/stdint.h https://en.wikibooks.org/wiki/C_Programming/stdint.h (in C99 :( ).
  - pjmlp 9y ago
    > They were that flexible because you'd compile ONE program ONCE for (any ported) platform and that was that. If it was ever so simple, specially given UB and compiler specific semantics across all those compilers and operating systems on the 90's (before C was hardly relevant outside UNIX).
- __s 9y ago
  http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdi... stdint even includes 'int with at least x bits' & 'fastest int type with at least x bits'
dom0 9y ago
Differing 64 bit data models don't really matter when software depending on exact widths uses exact width types. Unfortunately, on MSVC this hasn't been supported for many years out of the box, so each project had to include its own stdint.h replacement one way or another to do this.
int_19h 9y ago
This actually makes porting easier, not harder, in most cases, since code semantics remain the same. What makes porting complicated in general is dealing with pointers and handles. These are 32-bit or 64-bit, depending on the architecture. Unfortunately, it was pretty common for old code to assume that they're always 32-bit, and e.g. shove them into ints (WinAPI itself was guilty of this on many occasions). Technically, such a thing was never portable - not even with longs - until C99 brought us intptr_t, there was no guarantee that any integral type was large enough to hold a pointer. But in practice, it worked, so people did it.

by nikic 9y ago

khuey 9y ago

This particular problem was never really an issue for Mozilla, because the codebase has used fixed width types (first the NSPR types and later the stdint.h types) for 20 years.

user5994461 9y ago

To clarify: When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. The other compilers vary. The C standard only specifies that int has to be at least 32 bits. That's one of the many issues of porting from 32 to 64 bits.

syncsynchalt 9y ago
Sorry to nitpick, but the C standard specifies that int must be at least 16 bits, and that long is at least 32 bits. (Actually, it just specifies the minimum range, and tries not to be specific as to the bit representation). https://en.wikipedia.org/wiki/C_data_types https://en.wikipedia.org/wiki/C_data_types
- user5994461 9y ago
  Typo. I meant to write long, not int ^^
deleted 9y ago
[deleted]
cygx 9y ago
When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. That's not true for MinGW, and for good reasons (deviating from the ABI followed by the OS and all libraries would be stupid).

zeptomu 9y ago

If you think about it, I think its a little bit a fault of the language (AFAIK the C specification) defining basic integer types too loose. What is the advantage of having "int", "long" types that just give minimum byte requirements (with associated storage classes, etc.) instead of more specified types like int32_t and uint8_t? In the end you deal with fixed-size integers or not (using some bignum library), but if you deal with them you have to take their byte length into acount in your code anyway I would say (to deal with overflows and stuff).

deleted 9y ago
[deleted]
nnethercote 9y ago
I think the minimum sizes were chosen because of a combination of (a) there was a much greater variety of hardware available then, and (b) people hadn't learned that fixing these sizes is better.
mjevans 9y ago
They were that flexible because you'd compile ONE program ONCE for (any ported) platform and that was that. It took a little while, but eventually C got https://en.wikibooks.org/wiki/C_Programming/stdint.h https://en.wikibooks.org/wiki/C_Programming/stdint.h (in C99 :( ).
- pjmlp 9y ago
  > They were that flexible because you'd compile ONE program ONCE for (any ported) platform and that was that. If it was ever so simple, specially given UB and compiler specific semantics across all those compilers and operating systems on the 90's (before C was hardly relevant outside UNIX).
__s 9y ago
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdi... stdint even includes 'int with at least x bits' & 'fastest int type with at least x bits'

dom0 9y ago

Differing 64 bit data models don't really matter when software depending on exact widths uses exact width types. Unfortunately, on MSVC this hasn't been supported for many years out of the box, so each project had to include its own stdint.h replacement one way or another to do this.

int_19h 9y ago

This actually makes porting easier, not harder, in most cases, since code semantics remain the same. What makes porting complicated in general is dealing with pointers and handles. These are 32-bit or 64-bit, depending on the architecture. Unfortunately, it was pretty common for old code to assume that they're always 32-bit, and e.g. shove them into ints (WinAPI itself was guilty of this on many occasions). Technically, such a thing was never portable - not even with longs - until C99 brought us intptr_t, there was no guarantee that any integral type was large enough to hold a pointer. But in practice, it worked, so people did it.