|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2015-01-20 13:31 UTC] scott at smashcat dot org
Description:
------------
Currently the substr() function is inconsistent in its return value. Thus the value of the String object is affecting the type of object / primitive that is returned. Although the input String (shown below) is of zero length, it's still a String. So currently the returned value type needs to be checked by the calling code. To return a consistent type of value I suggest that either the last case should return an empty string, OR the substr() function should return boolean false if the input string is shorter than the required substr.
Test script:
---------------
substr("a",0,10);
substr("a",0,0);
substr("",0,10);
substr("",0,0);
Expected result:
----------------
substr("a",0,10) === false
substr("abc",0,1) === "a"
substr("",0,0) === ""
substr("",0,1) === false
Actual result:
--------------
substr("a",0,10) == "a"
substr("a",0,0) == ""
substr("",0,10) == false
substr("",0,0) == false
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 01 13:00:01 2025 UTC |
I would like to have substr("a",0,10) == "a" substr("a",0,0) == "" substr("",0,10) == "" substr("",0,0) == "" It would be nicer not to return FALSE for string and return maximum chars available upto specified length. What others think?I would not change the current behaviour. Too many PHP code is written based on that results. And the documentation is clear: substr("a",0,10); -> returns "a", I would expect that. If you do not like that, make an extra length() check before. substr("a",0,0); -> returns empty string, I epxect that, see documentation: http://php.net/manual/en/function.substr.php "If length is given and is 0, FALSE or NULL an empty string will be returned." substr("",0,10); and substr("",0,0); -> returns false, I would expect that, because the given input string is emtpy. There is no starting point, so false correct. The input variables are checked in order from the first to the last argument. So for me the behaviour is as expected and this is no bug and nothing should be changed.