Commited.
At 09:32 AM 9/10/2004 +0100, Joe Orton wrote:
On Tue, Aug 31, 2004 at 09:48:47PM -0700, Andi Gutmans wrote:
> It does look as if you're right. I don't quite understand why the standard
> was written in such a way and not in a way which only makes the value
> itself undefined.
> I think we
On Tue, Aug 31, 2004 at 09:48:47PM -0700, Andi Gutmans wrote:
> It does look as if you're right. I don't quite understand why the standard
> was written in such a way and not in a way which only makes the value
> itself undefined.
> I think we can apply the patch. Does anyone have a problem with
Hi Joe,
It does look as if you're right. I don't quite understand why the standard
was written in such a way and not in a way which only makes the value
itself undefined.
I think we can apply the patch. Does anyone have a problem with setting
arbitrary numbers such as LONG_MAX/LONG_MIN for an un
On Tue, Aug 31, 2004 at 12:02:31PM +0200, Derick Rethans wrote:
> On Tue, 31 Aug 2004, Joe Orton wrote:
>
> > On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
> > > On Tue, 31 Aug 2004, Joe Orton wrote:
> > >
> > > > Also, the bug27354 test needs to be updated since it relies on
> >
On Tue, 31 Aug 2004, Joe Orton wrote:
> On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
> > On Tue, 31 Aug 2004, Joe Orton wrote:
> >
> > > Also, the bug27354 test needs to be updated since it relies on
> > > particular behaviour of integers greater than LONG_MAX on 32-bit
> > > pl
On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
> On Tue, 31 Aug 2004, Joe Orton wrote:
>
> > Also, the bug27354 test needs to be updated since it relies on
> > particular behaviour of integers greater than LONG_MAX on 32-bit
> > platforms; since it looks like it is only really che
On Tue, 31 Aug 2004, Joe Orton wrote:
> Also, the bug27354 test needs to be updated since it relies on
> particular behaviour of integers greater than LONG_MAX on 32-bit
> platforms; since it looks like it is only really checking for
> not-a-division-by-zero-trap, this seems OK:
Yup, please commi
Also, the bug27354 test needs to be updated since it relies on
particular behaviour of integers greater than LONG_MAX on 32-bit
platforms; since it looks like it is only really checking for
not-a-division-by-zero-trap, this seems OK:
--- php-4.3.8/tests/lang/bug27354.phpt.dval2lval
+++ php-4.3.8/t
On Mon, Aug 30, 2004 at 04:40:13PM -0700, Andi Gutmans wrote:
> At 11:17 PM 8/30/2004 +0100, Joe Orton wrote:
> >On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote:
> >> I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
> >> better? It's not the kind of behavior which
At 11:17 PM 8/30/2004 +0100, Joe Orton wrote:
On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote:
> I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
> better? It's not the kind of behavior which I think we should "define".
C code which has undefined behaviour may segf
On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote:
> I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
> better? It's not the kind of behavior which I think we should "define".
C code which has undefined behaviour may segfault or suffer some other
run-time exception
I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
better? It's not the kind of behavior which I think we should "define".
In general, PHP always keeps the values as doubles if it detects that the
value is too low. This macro is only used when you force it, and I don't
think s
On Mon, Aug 30, 2004 at 12:32:59PM -0700, Andi Gutmans wrote:
> Hi Joe,
>
> It seems like your patch doesn't really fix anything. How is rounding to
> LONG_MAX/LONG_MIN any better?
The C standard says that when converting a double to a long, if the
integral part of the double is outside the rang
Hi Joe,
It seems like your patch doesn't really fix anything. How is rounding to
LONG_MAX/LONG_MIN any better?
Maybe you can explain in more detail what this gcc bug you are hitting is?
Thanks,
Andi
At 01:25 PM 8/27/2004 +0100, Joe Orton wrote:
The DVAL_TO_LVAL macro is quite weird, I'm not sure
The DVAL_TO_LVAL macro is quite weird, I'm not sure exactly what it's
supposed to be doing but it probably isn't doing it. If the integral
part of d is outside the range of a long, the conversion has undefined
behaviour by the C99 standard; an explicit cast makes no difference
AFAICT.
GCC on IA64
15 matches
Mail list logo
