Bug #61498 [Opn->Wfx]: htmlspecialchars() optional parameters and null
| From: | cataphract@php.net | Date: | Sat, 24 Mar 2012 22:19:49 +0000 |
| Subject: | Bug #61498 [Opn->Wfx]: htmlspecialchars() optional parameters and null | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-168808@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=61498&edit=1
ID: 61498
Updated by: cataphract@php.net
Reported by: francois dot gannaz at gmail dot com
Summary: htmlspecialchars() optional parameters and null
-Status: Open
+Status: Wont fix
Type: Bug
Package: Strings related
Operating System: Irrelevant
PHP Version: 5.3.10
Block user comment: N
Private report: N
New Comment:
Whether that expectation is legitimate is disputable. Setting another optional parameter usually
implies one has to explicitly provide the defaults for the previous parameters. Having null not have
the same effect has never been considered a bug (on the other hand, not being able to achieve the
same effect as not passing the parameter by passing a specific default value *has* been considered a
bug).
But when one considers adopting such "expected" behavior would result be a backwards
incompatible change, it seems to me that such a change is undesirable.
Previous Comments:
------------------------------------------------------------------------
[2012-03-24 17:20:24] francois dot gannaz at gmail dot com
Description:
------------
One would expect that when the optional $flags of htmlspecialchars() is set to null, the behavior is
the same as when the parameter is not set, so the default value is used.
This would be useful when someone wants to set another optional parameter. For instance, to set the
$double_encode parameter:
htmlspecialchars("some text", null, null, false);
Comment:
This is a bug similar to #40531 "mb_substr optional parameters". Other functions probably
behave the same. The difficulty is that zend_parse_argument() cannot deal with the complex type
"long or null", so extra parsing and validating is needed.
First tested on PHP 5.3.10, but same problem on 5.4.0.
Test script:
---------------
echo htmlspecialchars("l'été \"dernier\"\n");
echo htmlspecialchars("l'été \"dernier\"\n", null);
echo htmlspecialchars("l'été \"dernier\"\n", 0);
Expected result:
----------------
l'été "dernier"
l'été "dernier"
l'été "dernier"
Actual result:
--------------
l'été "dernier"
l'été "dernier"
l'été "dernier"
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=61498&edit=1