Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4467 > unrolled thread

Implied cast differs from explicit cast

Back to article view | Back to comp.lang.php

Contents

  Implied cast differs from explicit cast lb <lb2048@pobox.com.delete> - 2012-01-16 01:10 +0000
    Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-15 20:51 -0500
      Re: Implied cast differs from explicit cast lb <lb2048@pobox.com.delete> - 2012-01-16 03:08 +0000
        Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-15 22:39 -0500
          Re: Implied cast differs from explicit cast Arno Welzel <usenet@arnowelzel.de> - 2012-01-16 08:42 +0100
            Re: Implied cast differs from explicit cast Curtis Dyer <dyer85@gmail.com> - 2012-01-16 09:04 +0000
            Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-16 08:25 -0500
              Re: Implied cast differs from explicit cast "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-16 19:51 +0100
        Re: Implied cast differs from explicit cast The Natural Philosopher <tnp@invalid.invalid> - 2012-01-16 13:28 +0000
          Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-16 08:45 -0500
            Re: Implied cast differs from explicit cast Arno Welzel <usenet@arnowelzel.de> - 2012-01-17 06:59 +0100
              Re: Implied cast differs from explicit cast Arno Welzel <usenet@arnowelzel.de> - 2012-01-17 07:00 +0100
                Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-17 08:17 -0500
              Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-17 08:16 -0500
                Re: Implied cast differs from explicit cast Arno Welzel <usenet@arnowelzel.de> - 2012-01-19 13:36 +0100
                  Re: Implied cast differs from explicit cast Arno Welzel <usenet@arnowelzel.de> - 2012-01-19 13:39 +0100
                    Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-19 09:06 -0500
                  Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-19 09:05 -0500
                  Re: Implied cast differs from explicit cast The Natural Philosopher <tnp@invalid.invalid> - 2012-01-19 15:01 +0000
                    Re: Implied cast differs from explicit cast Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-19 14:41 -0500
    Re: Implied cast differs from explicit cast "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-16 09:49 +0100
    Re: Implied cast differs from explicit cast "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-01-16 11:48 +0100
      Re: Implied cast differs from explicit cast lb <lb2048@pobox.com.delete> - 2012-01-17 02:35 +0000

Page 2 of 2 — ← Prev page 1 [2]

#4476

Am 16.01.2012 02:10, schrieb lb:
> When converting some strings to int (or double), I am finding that
> an implied cast get different results from explicit cast. This happens
> when the string contains a hex representation. The implied cast converts
> the hex value, but the explicit cast returns 0. The manual under "String
> conversion to numbers" says nothing about it allowing hex values. This is
> with PHP-5.3.9 and older.
> 
> Script:
> <?php
> $s1 = '0x12';
> $t1 = $s1 + 0;
> echo "Implied cast t1=$t1\n";
> $t2 = (int)$s1 + 0;
> echo "Explicit cast t2=$t2\n";
> 
> Output:
> Implied cast t1=18
> Explicit cast t2=0
> 
> 
> I think this is odd. A side problem is that is_numeric('0x12') is true, but
> ((int)'0x12') is 0. Does anyone think this a bug?

I think it is odd. The notion of "hex string" does not make sense of it.

/Str.

[toc] | [prev] | [next] | [standalone]

#4479

El 16/01/2012 2:10, lb escribió/wrote:
> When converting some strings to int (or double), I am finding that
> an implied cast get different results from explicit cast. This happens
> when the string contains a hex representation. The implied cast converts
> the hex value, but the explicit cast returns 0. The manual under "String
> conversion to numbers" says nothing about it allowing hex values. This is
> with PHP-5.3.9 and older.
>
> Script:
> <?php
> $s1 = '0x12';
> $t1 = $s1 + 0;
> echo "Implied cast t1=$t1\n";
> $t2 = (int)$s1 + 0;
> echo "Explicit cast t2=$t2\n";
>
> Output:
> Implied cast t1=18
> Explicit cast t2=0
>
>
> I think this is odd. A side problem is that is_numeric('0x12') is true, but
> ((int)'0x12') is 0. Does anyone think this a bug?

Interesting subject... There are actually two different sections in the 
PHP manual:

*************************************************************************

Explicit cast:

http://es2.php.net/manual/en/language.types.integer.php#language.types.integer.casting

«To explicitly convert a value to integer, use either the (int) or 
(integer) casts. [...] A value can also be converted to integer with the 
intval() function.»

It admit it's not 100% clear but I have the impression that the 
underlying code is just the same and intval():

http://es2.php.net/manual/en/function.intval.php>

*************************************************************************

Implicit cast:

http://es2.php.net/manual/en/language.types.string.php#language.types.string.conversion

«When a string is evaluated in a numeric context, the resulting value 
and type are determined as follows.»

First difference is that you don't necessarily get an integer:

«If the string does not contain any of the characters '.', 'e', or 'E' 
and the numeric value fits into integer type limits (as defined by 
PHP_INT_MAX), the string will be evaluated as an integer. In all other 
cases it will be evaluated as a float.»

Second difference is that a standard C library is mentioned:

«For more information on this conversion, see the Unix manual page for 
strtod(3).»

... thus we can get further details:

http://linux.die.net/man/3/strtod

«The expected form of the (initial portion of the) string is optional 
leading white space as recognized by isspace(3), an optional plus ('+') 
or minus sign ('-') and then either (i) a decimal number, or (ii) a 
hexadecimal number, or (iii) an infinity, or (iv) a NAN (not-a-number).»

*************************************************************************

I believe the most relevant difference is that:

- intval() accepts any base but does not guess (defaults to 10)
- strtod() only accepts base 10 and 16 and does guess

... which explains your issue.

-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#4489

Thanks to all who replied, more or less...

I was not trying to convert hex to decimal or any such thing. I was
cleaning up some code that looked something like this:

  if (is_numeric($data[$i])) {
      $val = (double)$data[$i++];
      ...
  } else {
      $i++;
  }

I changed it to:
  if (is_numeric($val = $data[$i++])) {
      ...
  }

During testing I found that I could get different results within the
block with $val used as a numeric value in calculations. The difference
was when a string containing a hex value was used in the data array.
This is odd behavior, and inconsistant, in my opinion, and might be
considered a PHP bug.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web