# Looking for comments whether this is a bug or not

- Thread: https://externals.io/message/4304
- Original archive: https://news-web.php.net/php.internals/4304
- Started by Jeremy Johnstone on 2003-08-31T04:00:09+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #4306 — Ken Tossell — 2003-08-30T20:56:23+00:00

URL: https://externals.io/message/4304#4306 · In reply to: #4304

Your string assignments look wrong. For example, "\t" is a tab 
character. Try your test cases with 'This is a test email. Testing 
c:\test\foo.exe'; that should give you a proper string.

Ken

Jeremy Johnstone wrote:

>I am not sure if this is a bug, but I have came across two test cases
>where the behavior is not as expected so I thought I would ask.
>
>The problem I am having seems to be with addslashes not properly
>escaping this type of string "C:\test\foo.exe". Here is the scenario:
>
>$email->body = "This is a test email. Testing c:\test\foo.exe";
>
>When the $email object is later broke down and stored in the database
>addslashes is done (as it should be) before the variable is stored. 
>
>If you check the database though, no slashes were added to the string.
>The only way I can seem to get it to work as I thought it should, is to
>do the following:
>
>addslashes(str_replace("\\", "\\\\", $body))
>
>Then when you check the database you see the proper "This is a test
>email. Testing c:\\test\\foo.exe". 
>
>The other example I have is with an object which looks similar to:
>
>class login_handler 
>{
>
>	var last_ticket_subject;
>
>        // ... (code truncated)
>
>}
>
>If I set the class's last_ticket_subject to "This is a test
>c:\test\foo.com" later in the code, then do the following:
>
>addslashes(serialize($login_handler))
>
>and check the database, once again it didn't add any slashes. The only
>way I can get it to add the slashes as I think it should, is to do the
>following:
>
>addslashes(str_replace("\\", "\\\\", serialize($login_handler)))
>
>I am doing something wrong (or did I misunderstand something) or is this
>in fact a bug? I have tested it on PHP 4.2, 4.3.2, and 4.3.3 and the
>behavior is exactly the same. If it isn't a bug, can someone clarify for
>me why addslashes would be designed this way?
>
>Jeremy Johnstone

---

## #4304 — Jeremy Johnstone — 2003-08-31T04:00:09+00:00

URL: https://externals.io/message/4304#4304

I am not sure if this is a bug, but I have came across two test cases
where the behavior is not as expected so I thought I would ask.

The problem I am having seems to be with addslashes not properly
escaping this type of string "C:\test\foo.exe". Here is the scenario:

$email->body = "This is a test email. Testing c:\test\foo.exe";

When the $email object is later broke down and stored in the database
addslashes is done (as it should be) before the variable is stored. 

If you check the database though, no slashes were added to the string.
The only way I can seem to get it to work as I thought it should, is to
do the following:

addslashes(str_replace("\\", "\\\\", $body))

Then when you check the database you see the proper "This is a test
email. Testing c:\\test\\foo.exe". 

The other example I have is with an object which looks similar to:

class login_handler 
{

	var last_ticket_subject;

        // ... (code truncated)

}

If I set the class's last_ticket_subject to "This is a test
c:\test\foo.com" later in the code, then do the following:

addslashes(serialize($login_handler))

and check the database, once again it didn't add any slashes. The only
way I can get it to add the slashes as I think it should, is to do the
following:

addslashes(str_replace("\\", "\\\\", serialize($login_handler)))

I am doing something wrong (or did I misunderstand something) or is this
in fact a bug? I have tested it on PHP 4.2, 4.3.2, and 4.3.3 and the
behavior is exactly the same. If it isn't a bug, can someone clarify for
me why addslashes would be designed this way?

Jeremy Johnstone

---

## #4315 — Jeremy Johnstone — 2003-08-31T11:29:45+00:00

URL: https://externals.io/message/4304#4315 · In reply to: #4306

The actual value of those variables are pulled in from other sources,
they are not actually hard coded like I showed below. It was simply for
illustration purposes.

Jeremy


> Your string assignments look wrong. For example, "\t" is a tab 
> character. Try your test cases with 'This is a test email. Testing 
> c:\test\foo.exe'; that should give you a proper string.
> 
> Ken
> 
> Jeremy Johnstone wrote:
> 
> > […]

---

## #4320 — Curt Zirzow — 2003-08-31T15:11:49+00:00

URL: https://externals.io/message/4304#4320 · In reply to: #4304

* Thus wrote Jeremy Johnstone (jsjohnst@altdns.net):
> 
> $email->body = "This is a test email. Testing c:\test\foo.exe";
> 
> When the $email object is later broke down and stored in the database
> addslashes is done (as it should be) before the variable is stored. 
> 
> If you check the database though, no slashes were added to the string.

 `addslashes()` is working properly.  What you're experiencing is
the database servers' translation of '\\' -> '\'.

The documentation on addslashes explains this:
  http://php.net/addslashes


> I am doing something wrong (or did I misunderstand something) or is this
> in fact a bug? I have tested it on PHP 4.2, 4.3.2, and 4.3.3 and the

btw, you should post these questions to the php-general list,
especially when you are in doubt if you're using the function
properly.

Curt
-- 
"I used to think I was indecisive, but now I'm not so sure."

---

## #4324 — Jeremy Johnstone — 2003-08-31T16:10:10+00:00

URL: https://externals.io/message/4304#4324 · In reply to: #4320

> * Thus wrote Jeremy Johnstone (jsjohnst@altdns.net):
> > […]
database
> > […]
string.
> 
> `addslashes()` is working properly.  What you're experiencing is
> the database servers' translation of '\\' -> '\'.
> 
> The documentation on addslashes explains this:
>   http://php.net/addslashes

You might want to check the documentation again as it does not say
anything about the db server translating \\ into \. This seems highly
illogical, because if thats the case then addslashes("This is Jeremy's
test of c:\test\foo.exe") would get corrupted when you strippedslashes
after you pulled it back out of the database. If this is the case, which
database servers translate this way? I will then make sure I go update
the documentation accordingly. 

> 
> 
> > […]
this
> > […]
> 
> btw, you should post these questions to the php-general list,
> especially when you are in doubt if you're using the function
> properly.
> 

Actually I was quite sure I was using the function correctly, I said
that in case I misunderstood something in the documentation and thus
needed to update the documentation accordingly.

---

## #4325 — Curt Zirzow — 2003-08-31T19:01:53+00:00

URL: https://externals.io/message/4304#4325 · In reply to: #4324

* Thus wrote Jeremy Johnstone (jsjohnst@altdns.net):
> 
> > […]
> 
> You might want to check the documentation again as it does not say
> anything about the db server translating \\ into \. This seems highly
> illogical, because if thats the case then addslashes("This is Jeremy's
> test of c:\test\foo.exe") would get corrupted when you strippedslashes
> after you pulled it back out of the database. If this is the case, which
> database servers translate this way? I will then make sure I go update
> the documentation accordingly. 

I suppose it doesn't say that directly but it does explain what
characters  need to be quoted with the '\'. 

<quote http://php.net/addslashes>
Returns a string with backslashes before characters that need to be
quoted in database queries etc. These characters are single quote
('), double quote ("), backslash (\) and NUL (the `NULL` byte). 
</quote>

When to use `stripslashes()` and `addslashes()` depends on the
php.ini setting 'magic_quotes_gpc', as noted in both of the
functions documentation.

> > […]
> 
> Actually I was quite sure I was using the function correctly, I said
> that in case I misunderstood something in the documentation and thus
> needed to update the documentation accordingly.

I was letting you know that in future posts, questions regarding
proper use of functions or finding bugs should be posted to the
php-general list.


Curt
-- 
"I used to think I was indecisive, but now I'm not so sure."