Re: 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