[PHP-DOC] Re: [PHP-DEV] Integer casts broken or...? From: Jeroen van Wolffelaar (jeroen <email protected>)
Date: 05/16/01

In some really rare cases, but who is purposely using
(int) "0x... " anyway, and trusting on 0x being NOT
recognised??? And in user-submitted data, this just
adds another feature to most apps :), without any
programming.

The feature that non-numeric characters after the number
are ignored is only the best-of-worse-things to do
if you don't want to possible return errors on
casting to int.

Greetz,
Jeroen

On Wed, 16 May 2001, Brian Moon wrote:

> Making (int) recognize Hex values is a bad idea to me. It could potentially
> break current code.
>
> Brian Moon
> ------------------------------------------
> dealnews.com, Inc.
> Makers of dealnews & dealmac
> http://dealnews.com/ | http://dealmac.com/
>
> ----- Original Message -----
> From: "Jeroen" <jeroen <email protected>>
> To: ""Jeroen"" <jeroen <email protected>>; <torben <email protected>>; <brianm <email protected>>
> Sent: Wednesday, May 16, 2001 1:04 PM
> Subject: Re: [PHP-DEV] Integer casts broken or...?
>
>
> > > Brian Moon writes:
> > > > I know it would confuse me to have 0009 turned into an octal or hex if
> I
> > > > type cast it to (int). When I think of (int), I only think of their
> > > > ultimate decimal value. Perhaps there needs to be a new type cast
> > ((hex)?
> > > > (oct)?) that will interpret variables in their hex or octal value. I
> > know
> > > > it is still a long integer in value, but it is a different
> > representation of
> > > > that number.
> > >
> > > That's along the lines of what I was thinking--another cast (and
> > > perhaps an optional arg to intval()?) which would respect the
> > > base--maybe not separate (oct) or (hex)--or maybe so--or something
> > > like (intbase) which just respected the base (since octal and hex are
> > > the only ones strtol() claims to handle anyway). I admit that name is
> > > clumsy at best. :) As it stands is_numeric('0x24') returns true but
> > > intval('0x24') returns 0--which seems to conflict. Changing the
> > > existing cast would probably surprise a lot of people though :).
> >
> > A new cast is IMO no good idea. A cast is a way to enforce
> > converting to another TYPE, and that is not the case here.
> >
> > The default string -> int behaviour (is doesn't matter whether
> > implicit or explicit (resp. type-juggling and casting)) could
> > be improved to understand hex, but is definitely should NOT,
> > I repeat NOT understand octal numbers. Octal numbers
> > are obsolete (I've only seen them in chmod-like functions,
> > nowhere else.), and it would confuse a lot of people.
> > Mostly this function is called over user-supplied data,
> > and 90% of that users are still confused about why
> > the heck the internet uses forward-slashes, let alone
> > they know what octal means.
> > But it should be made possible of course, if you're certain
> > what you're doing.
> >
> > Summary:
> > - enhance string -> int conversion to understand hex.
> > - get an optional argument to intval as a possibility
> > to make it understand octals.
> >
> > What WOULD be nice cast (i realise i'm now contradicting
> > myself) is (number)
> > (number) $a
> > should be completely equivalent with
> > 0 + $a
> > that is, $a wil be converted to int if possible, but if it
> > is too large, or contains a fraction symbol (the dot)
> > or an exponent, it should be converted to float
> > instead.
> >
> >
> > Greetz,
> > Jeroen
> >
> >
> >
> >
> >
>
>

Jeroen van Wolffelaar
Jeroen <email protected>
http://www.A-Eskwadraat.nl/~jeroen