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
Hannes Landeholm landeholm@gmail.com 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?
Hannes Landeholm landeholm@gmail.com 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
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
hi,
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.
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
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
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
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.
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
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
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.
ITYM PHP uses "long" which unfortunately isn't long on windows.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227This 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
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
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.