Casting intval()

Client Joined: Oct 07, 2003 Posts: 735 Location: Ohio

intval() can be a good way to make sure variables passed are integers correct?

Such as if course_number are int(11) and I am passing this in the url I could do this...

Code:




$Course_Number = intval($_GET['Course_Number']);

registered · Posted: Tue Sep 09, 2008 3:52 pm

Correct, use intval() on all inputs you expect to be integers.

registered · Posted: Tue Sep 09, 2008 6:40 pm

In addition, the following is also appropriate:

$Course_Number = (int)$_GET['Course_Number'];

I suspect if nano-seconds of savings is important to you, this might be quicker. Laughing

Posted: Tue Sep 09, 2008 7:40 pm

I believe that's all the implementation of intval() actually does, a cast. There are many options that a compiler can do, probably PHP interpreter does the same.

For me, PHP being essentially typeless, casting statements like (int) look out of place. It's just my preference though.

Posted: Sat Sep 20, 2008 9:02 am

Intval() !- (int)

See the following:

Code:




<?php


$var = 'no number';





var_dump(intval($var));


var_dump((int)$var);

Posted: Sat Sep 20, 2008 10:56 am

Yes, confirming what we're saying from a functional viewpoint. Question now is which is faster? Are the internals of PHP compiling these into the same set of identical op-codes?

I honestly do not know.

Posted: Sat Sep 20, 2008 12:41 pm

Good question montego!

My experience lays in C(++) and there it realy does matter in memory flops.

For example you have an integer with the value 1 and you want to add 1:
$var = 1

With two memory blocks:

$var = $var + 1;
or
$var++;
or
$var+=1

Just one memory block:

++$var

That's why you see in my PHP code ++$var

Regarding the difference between (int) and intval() the difference is likewise.

intval() reads the string up untill no numerical character is found but, (int) does the same;
The only difference is that when no number is found there is no memory block with casting and with intval() there is.

To check wether there is a real difference you must look in the PHP C sourcecode to find out which code consumes the most memory blocks and lines of code.

The real speed increase doesn't lay within these premises, you just have to write code in less lines.

To increase speed in PHP 5, any object instance is passed by reference by default so that no copying occurs.

In your code think of the following:

$var = $_GET['foo'];

If foo doesn't exist, this produces a notice, which is another memory block!

$var = isset($_GET['foo']) ? (int)$_GET['foo'] : null;

Slower but no notice report and a proper use of 'null'.

$var = isset($_GET['foo']) ? (int)$_GET['foo'] : null;
$var = (int)$var;

Even slower!

However all the above doesn't really slow it down. Your database and PHP parser are the biggest concerns.
Memcache and good DB management do improve your application drastically.

DB is not noticeable on small sites, but take for example the ravennuke forums. They could be increased in speed drastically.
The difference is how you organize your database tables.
Why keep all posts of this massive forum in 1 table?
If you split it up like:
tbl_forums
tbl_forum_1
tbl_forum_2
tbl_forum_3

You will notice drastic improvements in CRUD:
1. There are smaller index files to update which improves disk IO and reordering of the index.
2. On SELECT the DB daemon doesn't have to look in 1 huge file to find each post his position which reduces disk IO

Of course there's one drawback. On search you have to look in many tables.
Solution for that is UNION, but is hard to use in the crappy protected DB layer in nuke.
And which comes back to: You should fix your PHP code!

I found a solution to the input issue of crappy coders in my new CMS.
It moves the content of $_GET and $_POST into a private variable of my static classes.
Then you must access the input like:

Code:

$var = GET::int('foo')

This is in similar to the "normal" PHP code:

Code:

$var = isset($_GET['foo']) ? (int)$_GET['foo'] : null;

However, my GET class also checks if the value is 100% a number!
So the code equaly is:

Code:

$var = (isset($_GET['foo']) && preg_match('#^-?\d+$#', $_GET['foo'])) ? (int)$_GET['foo'] : null;

The reason behind this, is simple:
$var = '100\'%20UNION';
Both (int) and intval() result in: 100
My GET::int() results in 'null' since it's not a valid number.
Therefore you can throw an error in your application that the input isn't valid.

It's just a way of thinking. Others think it's overhead.
To me it's Only registered users can see links on this board! Get registered or login! since nobody has to think about validating input (which they didn't most of the time anyway)

Posted: Sun Sep 21, 2008 7:35 am

djmaze, excellent info sir!

I completely agree with your approach. It is one thing to stop SQL injection (which inval/(int) does in this example), but allowing invalid input can also cause an incorrectly functioning application. Sometimes this is benign, but other times, it could actually be devastating depending on how the code is written.

Posted: Mon Sep 22, 2008 12:09 pm

With replies such as these to my questions is a perfect example of why ravenphpscripts ROCKS!!!

Posted: Wed Sep 24, 2008 5:57 am