Today while working on the MySQL connection tests with Unity3D I identified a bug in PHP. This bug concerns the stripslashes() function. This function should be used in conjunction with addslashes(), which add escape codes to ', ", \ and null while stripslashes() SHOULD remove them again.
Since these 2 functions are not native to MySQL, but PHP, I had to write them for Unity myself. Using an old copy of this blog locally, I have enough data to read and test, while I can edit it as I please on my local server. During these editings I found out that the \ was processed normally using addslashes(). But when I requested the blog entry on the local webserver, the \\ which was stored in the database was compeltely removed instead of returning a single \.
This is clearly a bug, because how else can we store stuff safely in a MySQL database..? And therefor I wanted to make a bugreport about the issue.
Having no account though (after having laid out the whole bug, I was shown similar reports and one caught my eye: https://bugs.php.net/bug.php?id=44876&edit=2. This report dates back to 2008 and describes the same bug I've encountered. But the response from the PHP.net team is just baffling: "This is expected behaviour and has always been this way.". Yeha, the description of the function is clear, but it's not conform it's counterpart addslashes().
Basically, a piece of code like:
should return '\' (without quoted) and not the empty string '' (without quotes, but hard to display an empty string without them )
Clearly there is no solution for this issue, other than make your own function in PHP to substitute stripslashes(). It's a good thing that I found this one so that I can change the code of the I am Blog project (eventhough I have declared it dead yesterday, but this is a bug I MUST fix).
...all instances of \ were changed manually in the database into 92; to make this post show up correctly...