Because of these kind of mass sanitizers : http://www.php.net/manual/en/function.filter-var-array.php and http://www.php.net/manual/en/function.filter-input-array.php
And to be able to use the mail filters instead of some yet again broken regexp.
I can understand email validation, but I can’t understand “sanitizing” email
I would never “sanitize” email by removing any character of it.
I think it has no sense.
Another example please.
Mail header injection anyone ? If some character can not, by the RFC, be part of an email address it should be deleted. But yeah, usually used more for validating than sanitizing.
I know, using the same kind of functions for 2 different things is evil for you. Well, I think the names of the filter is enough (and the all caps thing is like a blinking sign in the night) to see the difference.
Check the filter documentation for some examples.
If some character can not, by the RFC, be part of an email address it should be deleted.
Nope. Whole address should be rejected.
Check the filter documentation for some examples.
Unfortunately, there are same useless email example
Then you use a validating filter instead of sanitizing one. I even encourage you to start raising the php team attention about the FILTER_SANITIZE_EMAIL danger.
There are examples (even some user examples) for almost all functions. You should be able to find something usefull. If not, just continue using stripslashes, htmlentites, mysql_real_escape_string, and some preg_match.
I’d think of some of it
however mysql_real_escape_string does no validation nor sanitization.
and there are no filter with stripslashes functionality
Mysql_real_escape_string does sanitization for data expected to be put in a mysql database.
Correction, addslashes instead of stripslashes because php 5.2+ so stripslashes should be useless but for very rare and specific cases.
Quite contrary 
Addslashes is useless but for very rare and specific cases, while stripslashes is still useful for general use
Wise programmer would always add stripslashes routine to their code, just in case.
Define sanitization?
In my opinion, sanitizing stands for “to make something safe”.
Mysql_real_escape_string does not actually make any data “safe”. It is just part of syntax. Moreover, it’s only a part of process, which also involves adding quotes. Without quotes this function just helpless and won’t make any sanitization by any means.
Anyway, there are no mysql escape string validator
So, nothing to argue
Validation functions won’t help with database syntax and I will continue using mysql_real_escape_string(while you can switch to prepared statements which looks more fun for you)
Don’t tell me you’re using servers with magic_quotes on. This is the only case where stripslashes is not almost useless, and relying on magic_quotes is so php4.
About sanitization, mysql_real_escape string makes a string safe for a mysql query as it escape dangerous characters used for SQL injection (null characters for example). But parameterized queries are still a lot better with PDO or mysqli.
Btw, quotes are part of the SQL syntax, not of any safe making process.
Don’t tell me you’re using servers with magic_quotes on
I am answering questions here on sitepoint.
There are always some of them magic quotes related.
So it means that in the real world they are still exists
But parameterized queries are still a lot better
Define “a lot better”.
[1]About sanitization, mysql_real_escape string makes a string safe for a mysql query as it escape dangerous characters.
[2]quotes are part of the SQL syntax, not of any safe making process.
As a matter of fact, both [1] and [2] are parts of one mechanism and cannot be used separately (I have to explain it 2nd time within 24 hour on this forum). Make your mind for this: is it sanitization against injection (although there can be no user input at all) or just syntax rules.
OOP, not as prone to sql injection and not deprecated in the next php version.
And you can do multiple inserts easily without having to regenerate a SQL string (and without using sprintf for that).
Being sure a string has not unexpected characters : sanitization so mysql_real_escape_string.
Being sure something is a number : validation so (int)$id or
if(!is_numeric($id)){
die("bad");
}
Using ’ or " around strings in a sql query, not around numbers : syntax.
Your “unexpected characters” (whatever you mean with it) belongs to syntax.
Special characters must be escaped in every string you going to put into query.
It is not because someone going to inject something.
It is because it’s special characters that must be escaped by a syntax rule.
When writing application programs, any string that might contain any of these special characters must be properly escaped before the string is used as a data value in an SQL statement that is sent to the MySQL server. Period.
http://dev.mysql.com/doc/refman/5.0/en/string-syntax.html
Not a single word about sanitization or injection. Try to realize that.
It’s just a syntax rule.
mysql_real_escape_string is just the same syntax issue as quotes or backticks.
As for prepared statements, OOP is the only real advantage.
Other are just ridiculous, such as “depreciation” or “prone to sql injection”. You cannot prove any of these statements.
The only advantage I see in the prepared statements: noone tries to use it as input filter. As many people does for mysql_real_escape_string.
I can’t say one can call it “A lot better”.
When you understand what are you doing, no tool can be bad.
When you don’t - the best tool in the world will spoil you.
You got a point.
When you review some code and see :
mysql_query('select * from aTable where someField="'.$value.'"');
Knowing if it’s injection land is not obvious.
But if you see :
$stmt = $db->prepare('select * from aTable where someField=:value');
$stmt->execute(array(':value'=>$value));
You know the injection security is in the hands of the server admin staying up to date.
I have to agree with that.
To one who have no clue, prepared statements are safer.
I must warn you that prepared statements is not silver bullet.
And with this query
mysql_query("SELECT * FROM table ORDER BY $value");
Knowing if it’s injection land is not obvious. Especially for prepared statements users 
I too always get a bit confused by what is what, when to use it, and how.
I nearly always use it like the following:
GENERAL INPUT
stripslashes, strip_tags
DATABASE INPUT
mysql_real_escape_string, prepared statements, HTML Purifier(if HTML is going to be inserted)
OUTPUT
htmlspecialchars, htmlentities
Although, I really should look into PHP5’s filter.
Agreed. The library used may have exploits (hence the server admin job) and preparation is only for values, not field or table names. So sometimes you have to work it even with prepared statements.