Joe and Andi,
I agree that long long is probably questionable right now. Something
that seems debatable to me is: should we ever promote an integer type to
a floating type, simply on value? I guess it would make sense to
enumerate the schools of thought on this and the corresponding cast to a
So basically you're saying that we should return to previous behavior, right?
At 07:28 PM 10/5/2004 -0400, Noah Botimer wrote:
This bug report in particular caught my eye. I took some time to dig into
what's going on, and I've made some comments on the bug report page,
30315. The main idea is t
On Wed, Oct 06, 2004 at 08:56:15AM -0400, Noah Botimer wrote:
> Joe,
>
> This may be crazy, but does it make sense to think of integers in a more
> defined manner? That is, ``integer'' being equivalent to a long, which
> does have a guarantee on size (32-bit)? Also, some kind of long long
> t
Joe,
This may be crazy, but does it make sense to think of integers in a more
defined manner? That is, ``integer'' being equivalent to a long, which
does have a guarantee on size (32-bit)? Also, some kind of long long
type for 64-bit support would have to be included. I mean, consistency
is
On Tue, Oct 05, 2004 at 05:12:36PM -0700, Andi Gutmans wrote:
> At 02:17 PM 10/5/2004 +0200, Edin Kadribasic wrote:
> >On Tuesday 05 October 2004 14:02, Derick Rethans wrote:
> >> On Tue, 5 Oct 2004, Wez Furlong wrote:
> >> > Feels like a major bug to me... this got into a release? :-/
> >>
> >> Ye
On Tue, 5 Oct 2004, Andi Gutmans wrote:
> Actually I think it'd be a good idea to discuss it here on [EMAIL PROTECTED] We
> should reach some understanding about this problem and if we consider it a
> bug or not.
I'd say it's a bug, it breaks backwards compatibility...
Derick
--
Derick Rethans
At 02:17 PM 10/5/2004 +0200, Edin Kadribasic wrote:
On Tuesday 05 October 2004 14:02, Derick Rethans wrote:
> On Tue, 5 Oct 2004, Wez Furlong wrote:
> > Feels like a major bug to me... this got into a release? :-/
>
> Yes, please keep the discussion about this in the bugreport, and not on
> the lis
This bug report in particular caught my eye. I took some time to dig
into what's going on, and I've made some comments on the bug report
page, 30315. The main idea is that (positive) values over 2^31 are
being converted to float, and when casting back, they're being chopped
down to ``as big a
Actually I think it'd be a good idea to discuss it here on [EMAIL PROTECTED] We
should reach some understanding about this problem and if we consider it a
bug or not.
Andi
At 02:02 PM 10/5/2004 +0200, Derick Rethans wrote:
On Tue, 5 Oct 2004, Wez Furlong wrote:
> Feels like a major bug to me...
On Tuesday 05 October 2004 14:02, Derick Rethans wrote:
> On Tue, 5 Oct 2004, Wez Furlong wrote:
> > Feels like a major bug to me... this got into a release? :-/
>
> Yes, please keep the discussion about this in the bugreport, and not on
> the list.
This is exactly the place where things like this
On Tue, 5 Oct 2004, Wez Furlong wrote:
> Feels like a major bug to me... this got into a release? :-/
Yes, please keep the discussion about this in the bugreport, and not on
the list.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP R
Feels like a major bug to me... this got into a release? :-/
--Wez.
On Tue, 5 Oct 2004 13:30:00 +0300 (EEST), Tomas Kuliavas
<[EMAIL PROTECTED]> wrote:
> php-gettext classes (http://savannah.nongnu.org/projects/php-gettext)
> extract four bytes from gettext translation header, convert them to
> i
php-gettext classes (http://savannah.nongnu.org/projects/php-gettext)
extract four bytes from gettext translation header, convert them to
integer and use it to detect byteorder.
classes compare
(int) ((222) | (18<<8) | (4<<16) | (149<<24)) with (int)0x950412de
and
(int) ((149) | (4<<8) | (18<<16)
13 matches
Mail list logo
