php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #28899 mb_substr() and substr() work differently
Submitted: 2004-06-23 21:21 UTC Modified: 2005-12-23 12:19 UTC
Votes:6
Avg. Score:4.3 ± 0.9
Reproduced:5 of 5 (100.0%)
Same Version:4 (80.0%)
Same OS:5 (100.0%)
From: mauroi at digbang dot com Assigned: hirokawa (profile)
Status: Closed Package: mbstring related
PHP Version: 5CVS, 4CVS (2004-12-12) OS: *
Private report: No CVE-ID: None
View Developer Edit
 [2004-06-23 21:21 UTC] mauroi at digbang dot com 
Description:
------------
if I make the following call I get FALSE.

var_dump(substr('', 0));

The documentation says "If string is less than start characters long,
FALSE will be returned".
That can be very ambiguous because start is 0 and the length of the
string is 0 (not less).
Another problem: mb_substr does not work like this. If you overload the
functions and make the same call as above it will return an empty
string.

Thanks in advance.


Reproduce code:
---------------
var_dump(substr('', 0));
var_dump(mb_substr('', 0));


Expected result:
----------------
''
''

Or 

FALSE
FALSE

Actual result:
--------------
FALSE
''

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-06-23 22:12 UTC] moriyoshi@php.net 
Good catch. Logically it seems substr() is wrong and mb_substr() is correct.
 [2004-12-15 04:19 UTC] sniper@php.net 
The correct quote from up-to-date manual:
"If string is less than or equal to start characters long, FALSE  will be returned."

Notice the 'or equal' there?

Thus logically mb_substr() is buggy.
 [2004-12-20 10:28 UTC] moriyoshi@php.net 
The very nature of "substr" is that the function returns 
the specified part of the string whenever the range is 
valid and returns an error status if it is out of range.

If a null string is a valid string entity, then it 
should be able to be referred to by index "0" and thus 
the implementation returns a null string instead of 
false. Or you would say this isn't really logical? :)
 [2004-12-20 13:58 UTC] mauroi at digbang dot com 
just to mention it... lot of code written with the mb_* function overload relies on substr returning a zero length string... changing substr to work like mb_substr won't break anything (i think)
 [2005-02-03 03:25 UTC] sniper@php.net 
Whatever is the "logical" behaviour of the function, it doesn't really matter: We will NOT change the behaviour of substr() at this point. Thus the only place to change is mbstring.
 [2005-02-23 16:56 UTC] drraf at tlen dot pl 
If mb_string() can overload substr() (when function overloading in on when using mbstring) - in my opinion mb_substr() should be fixed.
 [2005-12-21 23:21 UTC] sniper@php.net 
Rui, can you check this please? Seems a bit odd that mbstring overloaded substr() works differently from the PHP core substr()..
 [2005-12-23 12:19 UTC] hirokawa@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

With this fix, when mbstring.func_overload is enable for string functions, mb_substr() will return FALSE for substr('', 0).
When mbstring.func_overload is disabled, mb_substr() will return ''.
 [2016-04-13 09:49 UTC] ab@php.net 
Related To: Bug #71971
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC