# 32 bit / 64 bit integer confusion - Thread: https://externals.io/message/53239 - Original archive: https://news-web.php.net/php.internals/53239 - Started by Hannes Landeholm on 2011-06-10T12:55:19+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53239 — Hannes Landeholm — 2011-06-10T12:55:19+00:00 URL: https://externals.io/message/53239#53239 Greetings. One very important feature of PHP is its interoperability. This allows my colleagues to work in both Windows, Ubuntu and OSX - developing the same application. Details like the fact that PHP will replace forward slash with backward slash automatically in windows is a great example of that. As a developer it's very important for me that the code executes exactly the same - no matter if the script is running on my development machine or in the production server. This is true for many other scripted languages. In javascript for example I expect an integer addition to return the same result - no matter the platform. At this point PHP is currently problematic since it for some reason - defines the integer size to depend on the current platform the code is running on which make no sense at all in my eyes. What are the reasoning behind this? I think the PHP integer size should be changed to always be 64 bit - independent of the platform. I have stumbled on this annoying inconsistency several times the last month. One specific use case for me where this causes problems is that I have integer ID columns in my database. I fully expect those to overflow above 2.1 billion at some point so then I suddenly have to be concerned if PHP is 32 or 64 bit compiled. Also, telling developers that "an integer always supports 64 bit" will make life much easier for them when they need it for implementing large numbers in cryptography, date arithmetics, scientific values, API interaction, etc etc. ~Hannes --- ## #53241 — Richard Riley — 2011-06-10T13:59:15+00:00 URL: https://externals.io/message/53239#53241 · In reply to: #53239 Hannes Landeholm writes: *snip button* Could anyone suggest why the php groups in particular mark post mime types incorrectly in certain instances? I am seeing ,---- | Content-Type: multipart/alternative; boundary=20cf301d426efd027f04a55b14cc `---- when there is only a single text part. Its playing havoc with my Gnus set up ;) I am viewing through gmane but dont have this elsewhere. Or is it just the posters themselves with incorrectly configured posting/email clients? --- ## #53242 — Derick Rethans — 2011-06-10T14:47:15+00:00 URL: https://externals.io/message/53239#53242 · In reply to: #53239 > What are the reasoning behind this? I think the PHP integer size > should be changed to always be 64 bit - independent of the platform. I > have stumbled on this annoying inconsistency several times the last > month. I agree that that should be the same. But sadly, Windows uses a different integer size model than almost everything else modern. Where Linux and Mac and other unices use 8 bytes for an "int", Windows uses 4 bytes (http://en.wikipedia.org/wiki/LP64#Specific_C-language_data_models). Because PHP internally uses "int" for its integer type, on Windows that's still only 32 bit. But yes, it would be awesome if PHP actually took care of this and uses 64 bit ints on 64 bit processors. > Also, telling developers that "an integer always > supports 64 bit" will make life much easier for them when they need it for > implementing large numbers in cryptography, date arithmetics, scientific > values, API interaction, etc etc. PHP's DateTime classes do use 64 bit integers internally, no matter on which processor (even 32bit ones). cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #53243 — Derick Rethans — 2011-06-10T14:51:53+00:00 URL: https://externals.io/message/53239#53243 · In reply to: #53241 > Hannes Landeholm writes: > > *snip button* > > Could anyone suggest why the php groups in particular mark post mime types > incorrectly in certain instances? I am seeing > > ,---- > | Content-Type: multipart/alternative; boundary=20cf301d426efd027f04a55b14cc > `---- > > when there is only a single text part. Its playing havoc with my Gnus > set up ;) I am viewing through gmane but dont have this elsewhere. > > Or is it just the posters themselves with incorrectly configured > posting/email clients? Yes, I think so. It's also not *incorrect*. It's perfectly acceptable to have a multipart/alternative with just one part. Derick --- ## #53244 — Pierre Joye — 2011-06-10T14:54:54+00:00 URL: https://externals.io/message/53239#53244 · In reply to: #53242 hi, > > > > […] > > I agree that that should be the same. But sadly, Windows uses a > different integer size model than almost everything else modern. > Where Linux and Mac and other unices use 8 bytes for an "int", Windows > uses 4 bytes (http://en.wikipedia.org/wiki/LP64#Specific_C-language_data_models). > Because PHP internally uses "int" for its integer type, on Windows > that's still only 32 bit. The sad part is not that windows uses a consistent type size across architecture but that linux and gcc considers that a type could be whatever the architecture uses. Hence why stdint.h was introduced and should be used instead of the long/int. > But yes, it would be awesome if PHP actually took care of this and uses > 64 bit ints on 64 bit processors. A type should be the same on all architecture, even more at the PHP script level. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53245 — Hannes Landeholm — 2011-06-10T15:01:51+00:00 URL: https://externals.io/message/53239#53245 · In reply to: #53244 > The sad part is not that windows uses a consistent type size across > architecture but that linux and gcc considers that a type could be > whatever the architecture uses. Hence why stdint.h was introduced and > should be used instead of the long/int. > Find/replace "int" -> "int64_t". Problem solved. ;) ~Hannes --- ## #53247 — Stas Malyshev — 2011-06-10T16:47:29+00:00 URL: https://externals.io/message/53239#53247 · In reply to: #53242 Hi! > I agree that that should be the same. But sadly, Windows uses a > different integer size model than almost everything else modern. > Where Linux and Mac and other unices use 8 bytes for an "int", Windows > uses 4 bytes (http://en.wikipedia.org/wiki/LP64#Specific_C-language_data_models). > Because PHP internally uses "int" for its integer type, on Windows > that's still only 32 bit. Erm... typedef union _zvalue_value { long lval; /* long value */ double dval; /* double value */ ITYM PHP uses "long" which unfortunately isn't long on windows. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53248 — Derick Rethans — 2011-06-10T16:52:49+00:00 URL: https://externals.io/message/53239#53248 · In reply to: #53247 > > […] > > Erm... > typedef union _zvalue_value { > long lval; /* long value */ > double dval; /* double value */ > > ITYM PHP uses "long" which unfortunately isn't long on windows. Yes, indeed. That was a typo. The original point still stands though. And IMO, this should be fixed in the Windows port so that on 64 bit processors, the PHP "int" type (the C "long" type) is actually 64 bits, just like almost any other current operating system/compiler set-up. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #53249 — johannes@schlueters.de — 2011-06-10T17:02:48+00:00 URL: https://externals.io/message/53239#53249 · In reply to: #53248 > Yes, indeed. That was a typo. The original point still stands though. > And IMO, this should be fixed in the Windows port so that on 64 bit > processors, the PHP "int" type (the C "long" type) is actually 64 bits, > just like almost any other current operating system/compiler set-up. While this will cause "strange" behavior when using "large" integers with some of our extension functions calling some c lib ... imagecreate(42949323647, 21444347483647); as a random example. (assuming one has enough ram ;-) ) johannes --- ## #53250 — John Crenshaw — 2011-06-10T17:08:11+00:00 URL: https://externals.io/message/53239#53250 · In reply to: #53247 > ITYM PHP uses "long" which unfortunately isn't long on windows. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 This is not exactly correct. I think what you meant to say, is "long isn't the same size as a pointer on Windows". Long us guaranteed only to be able to hold up to 4 bytes of data. That some platforms compile it to a size larger than 4 bytes is an unfortunate deviation from what (IMO) should be the norm of holding EXACTLY the minimum required size. In any case, any code that expects long to hold more than 4 bytes is fundamentally broken. See http://stackoverflow.com/questions/589575/c-size-of-int-long-etc#answer-589684 and http://jk-technology.com/c/inttypes.html#limits John Crenshaw Priacta, Inc. --- ## #53251 — Pierre Joye — 2011-06-10T17:13:48+00:00 URL: https://externals.io/message/53239#53251 · In reply to: #53250 > > > […] > > This is not exactly correct. I think what you meant to say, is "long isn't the same size as a pointer on Windows". One should never ever use long to store an address (pointer), just like one should never use int or long to store the length of a buffer (size_t). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53252 — Stas Malyshev — 2011-06-10T17:19:26+00:00 URL: https://externals.io/message/53239#53252 · In reply to: #53250 Hi! > This is not exactly correct. I think what you meant to say, is "long > isn't the same size as a pointer on Windows". I actually meant to say it's no longer than int, which makes this type kind of pointless currently. Both behaviors conform C standards and I'm sure there were reasons why Windows devs chose long to be not long, but it is unfortunate that this choice is different from most of other systems in existence. As for minimal ranges, I think they are quite outdated - there are not many 16-bit systems around anymore, so most ints would be 32-bit by now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53253 — John Crenshaw — 2011-06-10T17:23:52+00:00 URL: https://externals.io/message/53239#53253 · In reply to: #53252 > As for minimal ranges, I think they are quite outdated - there are not > many 16-bit systems around anymore, so most ints would be 32-bit by now. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 Yeah, the choice to make long longer and leave int in place is a bit of a historical deviation. The "int" type was always redundant, and previously it was int that moved, and the other types remained reliable. In any case, the stdint header should address the problem so long as it is used. John Crenshaw Priacta, Inc.