intval

Description

Returns the integer value of var,
using the specified base for the conversion
(the default is base 10). intval() should not be used
on objects, as doing so will emit an E_NOTICE level
error and return 1.

Parameters

var

The scalar value being converted to an integer

base

The base for the conversion

Note:

If base is 0, the base used is determined
by the format of var:

if string includes a "0x" (or "0X") prefix, the base is taken
as 16 (hex); otherwise,

if string starts with "0", the base is taken as 8 (octal);
otherwise,

the base is taken as 10 (decimal).

Return Values

The maximum value depends on the system. 32 bit systems have a
maximum signed integer range of -2147483648 to 2147483647. So for example
on such a system, intval('1000000000000') will return
2147483647. The maximum signed integer value for 64 bit systems is
9223372036854775807.

Strings will most likely return 0 although this depends on the
leftmost characters of the string. The common rules of
integer casting
apply.

You can have it automatically deduce the base of the number from the prefix of the string using the same syntax as integer literals in PHP ("0x" for hexadecimal, "0" for octal, non-"0" for decimal) by passing a base of 0 to intval():

Appears to be a floating point issue, but the number 1999 is the only number that I was able to get to do this. 19.99 is the price of many things, and for our purpose we must pass it as 1999 instead of 19.99.

Still have on mind, that if you convert big numbers by adding zero, PHP makes automatic "to a float" conversion, so it is same as floatVal(). So if the number is realy big (over 13 digits), you can lose preciosity. Do not use it for such long numbers, if all bits do matter (IPv6 addresses and similar).

Sometimes intval just won't cut it. For example if you want to use an unsigned 32-bit int and need all 32 bits. Recently, I wrote a little script that took and integer and converted it to an IP address. After realizing I couldn't just mod the whole thing, since the sign bit throws it off (and compensating for that), we ran into a problem where if it was entered into a form, the value somehow wasn't converted to an integer properly, at least not implicitly. The solution for this, and the way I recommend converting a string to an integer, is:

$num = $num + 0;

and PHP will leave your number alone; it'll just know it's a number. Such is the fun of a loosely-typed language. :)

As addendum, the "if ($int > 0)" check in the encode function is redundant. It doesn't do anything bad to keep it in since it will always be true when reaching that point, but it's a meaningless conditional this way. It's a remnant from when I tried to write the function in terms of bitshifts, which could lead to negative ints when shifting if the 32nd bit was set (instead of always padding with 0's when using >> it pads with 1's leading to negative ints).

The behaviour of intval() is interesting when supplying a base, and you better check your intval base-based expressions, as it is counter-intuitive.As the example shows<?php intval('42', 8); // => 34intval(42, 8); // => 42 !?>PHP considers the 42 as being already an integer, and doesn't apply any conversion. And supplying<?php intval(49, 8); // => 49 !?>produces no error and no warning.

This is nice if you want to turn a double into an int automatically rounding down

Hum, I had a bug earlier today, involving ===. Coming from a c++ background, I can't help testing for types. I was using floor() to get an integer from a division by 2, and comparing that to a known integer from a for loop. Well, first I changed the === to == because the test would always be false otherwise. Next, I looked up this function, and converted most of my floor() calls to intval() calls, because I really meant to get an int, and not a float with no decimal part. So I have to disagree with the editor note here. Oh, and I'm comfortably back to using ===.

I just wanted to be sure that a string was going to be valid if I intval'ed it. This regular expression matches:0Any positive integer (no + sign)Any negative integer (with a - sign)

It does not match a leading 0 or any other character. You are advised to strip out commas, trim the string and check range yourself ;)

<?php/** * Loops through each non-array element and actions a function. * * @return boolean|integer TRUE if the value matches as an integer, FALSE if * an error occured or 0 if not match was found. */public function validate($value){$value = preg_match('/^(0|(-{0,1}[1-9]\d*))$/', trim($value));

Re: nobodyisperfect88 at hotmail dot dejay at w3prodigy dot com had it right. I believe it is an issue with the floating point registers on computers, which have a precision of about 17 digits. When you get more precise than that, it rounds.

Since the second example can fit in the register, no rounding occurs, and PHP can truncate the portion after the decimal. However, the system automatically rounds the first example to 1, which is what PHP returns.

Since integers are stored on multiple bytes in the memory in binary format, once an signed long integer reaches the maximum value of 2147483646 (which is the maximum value that 8 bits of memory, size of a long int, can store, binary-wise), atleast on C/C++ the number starts to roll back, going gradually to ...45, ...45 and eventually reaching a negative value. Some REALLY large values will return -1, probably because PHP simply rejects the number, though I'm not sure why.

When you need to work with integer values that exceed maxint, the following functions may be of use to you - they form a codec pair for integers of variable length rather than fixed length, encoded in a byte as a 7 bit numberal with a 1 bit has-more flag, indicating that the next byte encodes a higher order part of the same number still.

This codec pair is also quite useful when needing to write ints to files, as this is a low-numeral biased encoding: most of the time this will only require 8 or 16 bit rather than the 32 bits an int will use in fixed-length encoding.

while indeed a 32 bit encoded variable length integer will be lower than maxint, rather than needing a new 32 bit block to represent higher range only 8 more bits are required to represent this higher number (for completeness the range of representation by bytes 5-8 are listed):

intval() returns maxint on number_in_string, if the result would be bigger than it. But for float returns the signed 32 bit integer with the "same" value:
<?php
$num=-1000;
print($num."\n");
$i_str=sprintf("%u",$num);
print($i_str."\n");
$i1=intval($i_str);
print($i1."\n");
$i2=intval(floatval($i_str));
print($i2."\n");
?>

intval used on bools returns either 1 or 0I usually use this to properly set bools in my tables (assuming you use some kind of int like tinyints as booleans) : <?php $myvar = 'right value';mysql_query('INSERT INTO mytable (activated) VALUES(' . intval($myvar === 'right value') . ')');?>

Say you have a string $s="3763328634" to be used as a key into the database, intval() this string will result in a different,smaller number (depends on the machine/OS). To keep the number intact but as an int/long type, do $s +=0; instead.

i guess one of the important usage of intval is in links , because : imagine that u have a function that uses get method (for example an integer id ) to retrieve the data from DB , so for example if you get " id=58 " in your link and put that in u'r function that retrieves data from DB , that's fine , it works wellbut what if some body put the " id=58djkdjsbvjkdsbvjkdbs " in the link ON PURPOSE !in such situation and condition he will get an Database error because u'r function retrieves Data from DB so it good to be use intval in such situationsbecause if u use that u gonna be sure that what ever that passes from u'r DB related function is just a integer , No text and any strange character !