Posted: Fri Oct 21, 2005 5:32 am
I'm banging my head on my desk here.. you have completely changed your argument.
You said you must add multiple checks to ensure the input is filtered. THAT is superfluous.
For your informatrion, as you obviously haven't worked it out yet, intval is a perfectly safe way to ensure the input is clear of all 'dangerous' characters, unless MySQL have suddenly decided that some Int char's are special chars..
At no point in my example or anywhere else is only some input escaped, if you care to read up on the function intval() you will realise that any char's not equivocal to an Int are removed, i.e. if it aint 0-9, it doesn't get returned.
So.. if you know the input should be an int (and ID field is a perfect example..) then using intval is a perfectly acceptable method to filter, validate and escape, all in once step
After all, in an integer value has nothing to escape with a slash, does it? So what good does using mysql_real_escape_string or any regex do? 
Code, such as escaping an integer value, after it has been filtered by intval() is superfluous, thus not optimal.
BTW - you do not 'prepare' for developers cock ups. If they are going to remove the intval(), they could do any manner of cock ups, which none are my 'fault' (as that is what you seem more worried about).
I've never, ever seen a developer add in extra code just to satisfy the incompetence of possible future developers, because, like I said, it is poor practice to include extra code just for this purpose. This is what the documentation and comments are for.
You said you must add multiple checks to ensure the input is filtered. THAT is superfluous.
For your informatrion, as you obviously haven't worked it out yet, intval is a perfectly safe way to ensure the input is clear of all 'dangerous' characters, unless MySQL have suddenly decided that some Int char's are special chars..
At no point in my example or anywhere else is only some input escaped, if you care to read up on the function intval() you will realise that any char's not equivocal to an Int are removed, i.e. if it aint 0-9, it doesn't get returned.
So.. if you know the input should be an int (and ID field is a perfect example..) then using intval is a perfectly acceptable method to filter, validate and escape, all in once step
Code, such as escaping an integer value, after it has been filtered by intval() is superfluous, thus not optimal.
BTW - you do not 'prepare' for developers cock ups. If they are going to remove the intval(), they could do any manner of cock ups, which none are my 'fault' (as that is what you seem more worried about).
I've never, ever seen a developer add in extra code just to satisfy the incompetence of possible future developers, because, like I said, it is poor practice to include extra code just for this purpose. This is what the documentation and comments are for.