| HN Mirror

I know it feels tired to dunk on things like this, but I feel like this is the “original sin” of PHP. Lerdorf built a language for himself, it appealed to other developers with this attitude, and eventually they became the people driving the language forward, propagating the problem into the future. Pretty much everything people dislike about PHP today can be traced back to this mentality.

> And don't even get me started about mysql_real_escape_string! It has the word "real" in it. I mean, come on, who would ever name a function "real", and why?

> [...]

> The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the PHP community.

The reasoning for this boils down to historic reasons and backwards compatibility. And the naming here isn't even PHP's fault at all, so maybe rethink your rant a bit!

Correctly escaping a bind variable string in MySQL depends on the connection's character set, since a few rarely-used character sets involve more complexity with escaping. But full support for character sets wasn't added to MySQL until version 4.1, released 20 years ago in 2004.

So prior to that, in the MySQL C client API, you could safely escape strings using the mysql_escape_string C function. But after connection-level character sets were added, this was no longer sufficient. And you can't change the function signature in a widely-used C library without breaking all prior users of the library. So the MySQL C client API introduced mysql_real_escape_string to solve this, which takes a connection pointer as its first parameter, and then deprecated the old mysql_escape_string at the same time.

So then PHP added their mysql_real_escape_string to match this, and deprecated the old mysql_escape_string, but did not remove it because it would break all old programs. And at the time two decades ago, this actually made sense! Many of those old programs were still using pre-4.1 MySQL (since 4.1 was still brand new), in which case the old mysql_escape_string was still perfectly secure, since connections didn't have character sets.

Today it's clear that both PHP and MySQL should have acted more aggressively to remove the deprecated connectionless mysql_escape_string shortly after this all happened. But from my memory, the industry's views on security vs backwards compatibility were quite different 20 years ago than they are today.

Great comment. Didn't know the history behind this even though I've been coding php since v3.

Thanks! I should add a disclaimer that I was writing it from memory, as a random programmer who started using PHP 4 and MySQL 3.23 in 2003, i.e. I wasn't a direct contributor to the language or database.

After further reflection, some of the fine details in my comment above may be off. I vaguely remember MySQL having a single server-wide (I believe?) configurable charset option before MySQL 4.1, so it's likely the MySQL C client library API gained mysql_real_escape_string earlier than 4.1.

Anyway though the broad point remains -- PHP didn't pick the "real_" naming, MySQL did; and the reason for MySQL's API there makes more sense in the historical context of expanding charset support, and needing a different C function signature to accept a connection arg.

And fwiw I do agree that "real" is a rather poor choice for this sort of API naming, but I assume the MySQL folks just went with that to avoid an excessively-long function name... also the developers of MySQL weren't native English speakers. Anyway, hindsight is 20/20 and all that.