Re: [PHP-DEV] double val to long val conversion issue
Hi! On x86_64 (so, with or without -O2) $ gcc -O2 -Wall math2.c -o math2 ./math2 9223372036854775807 double=9223372036854775808 signed=8000 unsigned=8000 On ppc64 $ gcc -O2 -Wall math2.c -o math2 ./math2 9223372036854775807 double=9223372036854775808 signed=0x7f unsigned=8000 So, looks like on ppc64 double-long conversion works differently than on x86_64. Maybe best solution would be to make the patch with ifdef for ppc64 so that it would do the same as Intel... Though I'm not sure if somebody on this platform would expect PHP behave as C does, or as Intel counterpart does. I'd say I personally probably would prefer Intel-compatible behavior since most software would be expected to be tested on Intel. But formally I'm not sure it's even wrong behavior... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
On Sun, 10 Feb 2013 09:35:41 +0100, Stas Malyshev smalys...@sugarcrm.com wrote: So, looks like on ppc64 double-long conversion works differently than on x86_64. Maybe best solution would be to make the patch with ifdef for ppc64 so that it would do the same as Intel... Though I'm not sure if somebody on this platform would expect PHP behave as C does, or as Intel counterpart does. I'd say I personally probably would prefer Intel-compatible behavior since most software would be expected to be tested on Intel. But formally I'm not sure it's even wrong behavior... I don't think the ifdef is needed at all. Like I said in the bug report, I'm pretty sure that the patch is correct. The idea of casting first to unsigned long when d (double)LONG_MAX is to use the extra range of unsigned long; if the double is within unsigned long, the result is well-defined. But that test has a hidden assumption: if d == (double)LONG_MAX, then we can cast to (long) because d is within the long range. This assumption is wrong because (double)LONG_MAX is larger than LONG_MAX -- the value 9223372036854775808.0 is the closest double to 9223372036854775807. Therefore, changing the test to = seems to be the correct course of action. My concern is that we may also have different behavior when we go outside the unsigned long range. As to whether ppc64 or x86_64 is correct when casting (double)LONG_MAX to a signed long, the answer is this that since the double is outside long range, the behavior is undefined. If we want more predictability, we have to do the conversion ourselves and probably take a small performance hit. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
On 10/02/13 06:50, Stas Malyshev wrote: isn't the case with visualC, and PHP internal data structures compiled with visualC and gcc are significantly different; for example hash keys are 32 bits long on Windows and 64bits on *nix. Why aren't they 32bits, Yes, they are different, because long size is different, This my point: programmers from the *nix world tend to assume that longs are longer than ints. In the MS world they are synonymous. This is one reason why code that has been developed in the *nix can be difficult to get working reliably in the MS world. and PHP uses long (more specific, ulong) to store hash values. This is because numeric values are long, I don't follow this reasoning. Numeric value in this context is a PHP (application space) concept. Hashes are internal to the Zend EE and are never exposed to the PHP programmer, so this is a case of comparing apples and pears. All that having a 64-bit hash does (when used % nTableSize which smaller than maxint) is to add 8 bytes to every Bucket entry stored by the EE for no practical benefit. (It's 8 bytes because ulong h; uint nKeyLength; long boundary takes 16 bytes but uint32 h; uint nKeyLength; long boundary takes 8 because of data alignment.) and it's easier to use the same type for both than bother with converting back and forth. As you noted, the difference for hashing is minimal since the value is anyway brought to hash size, and hashes of size more than 32-bit LONG_MAX aren't very practical. However, it matters in other parts of the code.
Re: [PHP-DEV] double val to long val conversion issue
On Sun, 10 Feb 2013 12:00:01 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
My concern is that we may also have different behavior when we go
outside the unsigned long range.
As to whether ppc64 or x86_64 is correct when casting (double)LONG_MAX
to a signed long, the answer is this that since the double is outside
long range, the behavior is undefined. If we want more predictability,
we have to do the conversion ourselves and probably take a small
performance hit.
If we want to eliminate the undefined behavior, we should do (on archs
with 64-bit longs):
(long)(unsigned long)(fmod(d, pow(2., 64.)))
Can you test this program on ppc64:
#include stdio.h
#include math.h
long convert(double d)
{
return (long)(unsigned long)(fmod(d, pow(2., 64.)));
}
int main(int argc, char *argv[])
{
double d;
if (argc 1 sscanf(argv[1], %lg, d)) {
printf(%ld %ld\n, convert(d), (long)(unsigned long)d);
}
return 0;
}
I get this:
$ gcc -O3 -lm conv.c ./a.out 9223372036854775808
-9223372036854775808 -9223372036854775808
$ gcc -O3 -lm conv.c ./a.out 4e21
-2943463994972700672 0
$ gcc -O3 -lm conv.c ./a.out 4e19
3106511852580896768 0
Which seems correct when verified with mathematica:
In[9]:= c =
Function[o,
o // N // SetPrecision[#, \[Infinity]] // Mod[#, 2^64] //
Piecewise[{{#, # 2^63}}, -2^64 + #] ];
In[10]:= c /@ {2^63, 4*^21, 4*^19}
Out[10]= {-9223372036854775808, -2943463994972700672, \
3106511852580896768}
The cast to long from unsigned long is still implementation-defined
behavior, but all twos complement archs should work like this (i.e. don't
change the representation). In any case, it's not undefined behavior.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Le 10/02/2013 15:58, Gustavo Lopes a écrit : If we want to eliminate the undefined behavior, we should do (on archs with 64-bit longs): (long)(unsigned long)(fmod(d, pow(2., 64.))) Can you test this program on ppc64: $ gcc -O3 -lm conv.c ./a.out 9223372036854775808 -9223372036854775808 -9223372036854775808 $ gcc -O3 -lm conv.c ./a.out 4e21 -2943463994972700672 -1 $ gcc -O3 -lm conv.c ./a.out 4e19 3106511852580896768 -1 I get this: $ gcc -O3 -lm conv.c ./a.out 9223372036854775808 -9223372036854775808 -9223372036854775808 $ gcc -O3 -lm conv.c ./a.out 4e21 -2943463994972700672 0 $ gcc -O3 -lm conv.c ./a.out 4e19 3106511852580896768 0 Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Travis-CI support for the latest PHP Release Candidate
https://github.com/travis-ci/travis-ci/issues/920 There was a recent thread about testing against PHP 5.5 using Travis-CI. I thought this might make it even easier to get feedback on which projects are having problems with the Release Candidates. -- Herman Radtke @hermanradtke | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
On Feb 10, 2013 7:25 PM, Dennis Clarke dcla...@blastwave.org wrote: Dear PHP folks : I am trying to build php 5.4.11 with the GD extension and running into an error where both GCC 4.7.2 and Oracle Studio 12.3 claim that : /usr/local/build/php-5.4.11_SunOS5.10_sparcv9+GD.001/ext/gd/gd_ctx.c, line 51: error: improper member use: data /usr/local/build/php-5.4.11_SunOS5.10_sparcv9+GD.001/ext/gd/gd_ctx.c, line 58: error: improper member use: data /usr/local/build/php-5.4.11_SunOS5.10_sparcv9+GD.001/ext/gd/gd_ctx.c, line 67: error: improper member use: data There is a problem when an external library is used. Using the bundled lib fixes this problem (--with-gd) Cheers, Pierre
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
- Original Message - From: Pierre Joye pierre@gmail.com Date: Sunday, February 10, 2013 1:55 pm Subject: Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data' To: Dennis Clarke dcla...@blastwave.org Cc: Stanislav Malyshev s...@php.net, Christopher Jones christopher.jo...@oracle.com, PHP internals internals@lists.php.net, s...@php.net, Rasmus Lerdorf ras...@php.net On Feb 10, 2013 7:25 PM, Dennis Clarke dcla...@blastwave.org wrote: Dear PHP folks : I am trying to build php 5.4.11 with the GD extension and running into an error where both GCC 4.7.2 and Oracle Studio 12.3 claim that : /usr/local/build/php-5.4.11_SunOS5.10_sparcv9+GD.001/ext/gd/gd_ctx.c, line 51: error: improper member use: data /usr/local/build/php-5.4.11_SunOS5.10_sparcv9+GD.001/ext/gd/gd_ctx.c, line 58: error: improper member use: data /usr/local/build/php-5.4.11_SunOS5.10_sparcv9+GD.001/ext/gd/gd_ctx.c, line 67: error: improper member use: data There is a problem when an external library is used. Using the bundled lib fixes this problem (--with-gd) Thank you for the nearly instant neck breaking speedy response ! OKay, so this means that my build of GD 2.0.33 ( http://www.boutell.com/gd/manual2.0.33.html ) was perhaps a waste of time and I will have a go with your suggestion right away. node002 $ rm ../php-5.4.11_SunOS5.10_sparcv9.001.cache node002 $ ./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \ --with-libxml-dir=/usr/local --sysconfdir=/usr/local/etc \ --includedir=/usr/local/include --libdir=/usr/local/lib \ --libexecdir=/usr/local/libexec --localstatedir=/usr/local/var/php \ --mandir=/usr/local/share/man --infodir=/usr/local/share \ --cache-file=../php-5.4.11_SunOS5.10_sparcv9.001.cache --disable-debug \ --with-pic --with-bz2 --with-gettext --with-gmp --with-iconv --with-openssl \ --with-zlib --enable-ftp --enable-sockets --without-kerberos \ --enable-calendar --enable-xml --disable-json --with-curl=/usr/local \ --enable-posix --with-pdo-mysql --enable-mbstring --with-mysqli \ --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --with-zlib-dir=/usr/local --with-xpm-dir=/usr/openwin/lib/sparcv9 \ --with-gd --with-freetype-dir=/usr/local . . . well golly gee .. it didn't blow up in the first 5 minutes. Still compiling ... :-) Thank you very much. Does this mean there is a fork of GD inside the php source tarballs and that the stuff I see at Tom Boutell's site is just something else ? Dennis ps: as an aside, I'd love to solve those warnings about ./Zend/zend_operators.h, line 597: warning: integer overflow detected: op however it looks like a funky define does the deed and it seems to roll an integer left by 8 * sizeof(long) - 1. Not sure what the intent of that is. Could be just to isolate a single upper bit ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
On Sun, 10 Feb 2013 16:19:46 +0100, Remi Collet r...@fedoraproject.org
wrote:
Le 10/02/2013 15:58, Gustavo Lopes a écrit :
Can you test this program on ppc64:
$ gcc -O3 -lm conv.c ./a.out 9223372036854775808
-9223372036854775808 -9223372036854775808
$ gcc -O3 -lm conv.c ./a.out 4e21
-2943463994972700672 -1
$ gcc -O3 -lm conv.c ./a.out 4e19
3106511852580896768 -1
I get this:
$ gcc -O3 -lm conv.c ./a.out 9223372036854775808
-9223372036854775808 -9223372036854775808
$ gcc -O3 -lm conv.c ./a.out 4e21
-2943463994972700672 0
$ gcc -O3 -lm conv.c ./a.out 4e19
3106511852580896768 0
This was I was afraid. That bug was just the tip of the iceberg. I suggest
we do change the the operator to = like you proposed, but also that we
add the fmod call. The code I gave earlier had a bug btw, as fmod can give
a negative number. I changed it to this:
long convert(double d)
{
double dmod = fmod(d, pow(2., 64.));
if (dmod 0) {
dmod += pow(2., 64.);
}
return (long)(unsigned long)dmod;
}
I tested the doubles around -4e21 and it worked fine:
$ ./a.out -4001048576
2943463994971652096 -9223372036854775808
$ ./a.out -4000524288
2943463994972176384 -9223372036854775808
$ ./a.out -40
2943463994972700672 -9223372036854775808
$ ./a.out -3999475712
2943463994973224960 -9223372036854775808
$ ./a.out -3998951424
2943463994973749248 -9223372036854775808
In[36]:= c /@ Table[-4.*^21 + i*Ulp[-4.*^21], {i, -2, 2}]
Out[36]= {2943463994971652096, 2943463994972176384, \
2943463994972700672, 2943463994973224960, 2943463994973749248}
Any reservations?
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
There is a problem when an external library is used. Using the bundled lib fixes this problem (--with-gd) That worked beautifully : gd GD Support enabled GD Version bundled (2.0.34 compatible) FreeType Supportenabled FreeType Linkagewith freetype FreeType Version2.4.11 GIF Read Supportenabled GIF Create Support enabled JPEG Supportenabled libJPEG Version unknown PNG Support enabled libPNG Version 1.5.14 WBMP Supportenabled XPM Support enabled libXpm Version 30411 XBM Support enabled Not sure why libJPEG is an unknown version but other than that .. looks great. Thank you so much. Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
Dennis Clarke in php.internals (Sun, 10 Feb 2013 14:50:25 -0500):
libJPEG Versionunknown
Not sure why libJPEG is an unknown version but other than that .. looks great.
Because you are using version 9.0 and ext/gd/libgd/gd_jpeg.c does not
know anything about that version. There should be a generic check for
the libJPEG version. Something like
char jpegstr[12];
const char * gdJpegGetVersionString()
{
switch(JPEG_LIB_VERSION) {
case 62:
return 6b;
break;
case 70:
return 7;
break;
case 80:
return 8;
break;
default:
snprintf(jpegstr, sizeof(jpegstr), %d, JPEG_LIB_VERSION);
return jpegstr;
}
}
But I know there are better solutions (looking at ext/gd/gd.c).
Jan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
On Sun, Feb 10, 2013 at 2:50 PM, Dennis Clarke dcla...@blastwave.org wrote: Does this mean there is a fork of GD inside the php source tarballs and that the stuff I see at Tom Boutell's site is just something else ? I would like to know the answer to that myself. The gd project is currently maintained by the PHP community. I'm not sure if what's in the PHP tarballs is different from what's on bitbucket and to what degree. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
hi Tom, On Sun, Feb 10, 2013 at 11:54 PM, Tom Boutell t...@punkave.com wrote: On Sun, Feb 10, 2013 at 2:50 PM, Dennis Clarke dcla...@blastwave.org wrote: Does this mean there is a fork of GD inside the php source tarballs and that the stuff I see at Tom Boutell's site is just something else ? I would like to know the answer to that myself. The gd project is currently maintained by the PHP community. I'm not sure if what's in the PHP tarballs is different from what's on bitbucket and to what degree. Actually the bitbucket branch has more features (image formats support and a couple of handy features like autocroping and the likes). 5.5 will bring both in sync and will use bundled versions when php is built against an older version. But this bug is a binary incompatibility with the external lib, my mistake while adding a long awaited feature. To restore the binary compatibility will require some re-factoring, 5.5 final should have it and the other branches will follow shortly after. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Le 10/02/2013 20:27, Gustavo Lopes a écrit :
This was I was afraid. That bug was just the tip of the iceberg. I
suggest we do change the the operator to = like you proposed,
I will do it later today.
but also that we add the fmod call. The code I gave earlier had a bug btw,
as fmod can give a negative number. I changed it to this:
long convert(double d)
{
double dmod = fmod(d, pow(2., 64.));
if (dmod 0) {
dmod += pow(2., 64.);
}
return (long)(unsigned long)dmod;
}
I tested the doubles around -4e21 and it worked fine:
On ppc64,
$ gcc -O2 -Wall conv.c -o conv -lm
$ ./conv -4001048576
2943463994971652096 -9223372036854775808
$ ./conv -4000524288
2943463994972176384 -9223372036854775808
$ ./conv -40
2943463994972700672 -9223372036854775808
$ ./conv -3999475712
2943463994973224960 -9223372036854775808
$ ./conv -3998951424
2943463994973749248 -9223372036854775808
$ ./conv 9223372036854775808
-9223372036854775808 -9223372036854775808
$ ./conv 4e21
-2943463994972700672 -1
$ ./conv 4e19
3106511852580896768 -1
$ ./a.out -4001048576
2943463994971652096 -9223372036854775808
$ ./a.out -4000524288
2943463994972176384 -9223372036854775808
$ ./a.out -40
2943463994972700672 -9223372036854775808
$ ./a.out -3999475712
2943463994973224960 -9223372036854775808
$ ./a.out -3998951424
2943463994973749248 -9223372036854775808
In[36]:= c /@ Table[-4.*^21 + i*Ulp[-4.*^21], {i, -2, 2}]
Out[36]= {2943463994971652096, 2943463994972176384, \
2943463994972700672, 2943463994973224960, 2943463994973749248}
Any reservations?
For which values ? Outside LONG_MIN .. ULONG_MAX ?
Remi.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Hi! This was I was afraid. That bug was just the tip of the iceberg. I suggest we do change the the operator to = like you proposed, I will do it later today. = may be fine, but I am concerned about fmod change for 5.4. If we do it, I'm afraid we may change some scenario, so I'd prefer to make it 5.5 only. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
