php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61498 htmlspecialchars() optional parameters and null
Submitted: 2012-03-24 17:20 UTC Modified: 2012-03-24 22:19 UTC
From: francois dot gannaz at gmail dot com Assigned:
Status: Wont fix Package: Strings related
PHP Version: 5.3.10 OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: francois dot gannaz at gmail dot com
New email:
PHP Version: OS:

 

 [2012-03-24 17:20 UTC] 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"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-24 22:19 UTC] cataphract@php.net
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.
 [2012-03-24 22:19 UTC] cataphract@php.net
-Status: Open +Status: Wont fix
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 01:01:28 2024 UTC