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" <[EMAIL PROTECTED]> > To: ""Jeroen"" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[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 [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
