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 p
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
hi Tom,
On Sun, Feb 10, 2013 at 11:54 PM, Tom Boutell wrote:
> On Sun, Feb 10, 2013 at 2:50 PM, Dennis Clarke 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
On Sun, Feb 10, 2013 at 2:50 PM, Dennis Clarke 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 PH
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 shoul
> 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 Versio
On Sun, 10 Feb 2013 16:19:46 +0100, Remi Collet
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
- Original Message -
From: Pierre Joye
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
Cc: Stanislav Malyshev , Christopher Jones
, PHP internals
On Feb 10, 2013 7:25 PM, "Dennis Clarke" 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
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/p
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://hermanrad
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
-9223372036854
On Sun, 10 Feb 2013 12:00:01 +0100, Gustavo Lopes
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
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 si
On Sun, 10 Feb 2013 09:35:41 +0100, Stas Malyshev
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 platf
hi Terry.
On Sun, Feb 10, 2013 at 12:02 AM, Terry Ellison wrote:
> On 09/02/13 15:47, Pierre Joye wrote:
>
> hi Remi
>
> On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet wrote:
>
> About
> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
> (For now, I have rev
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=
17 matches
Mail list logo
