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

go to bug id or search bugs for

Bug #42142 substr_replace() returns FALSE
Submitted: 2007-07-29 22:54 UTC Modified: 2007-07-30 14:22 UTC
From: fznohluwlempsh at mailinator dot com Assigned: iliaa (profile)
Status: Closed Package: Strings related
PHP Version: 5.2.3 OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: fznohluwlempsh at mailinator dot com
New email:
PHP Version: OS:

 

 [2007-07-29 22:54 UTC] fznohluwlempsh at mailinator dot com 
Description:
------------
After upgrading from 5.2.1 to 5.2.3, my app broke. Why? Because I had the audacity to use substr_replace() in a perfectly reasonable way.

This isn't rocket science. If $length is longer than the length of $string, substr_replace() should return the same as if $length was not given. It should not return FALSE. Hell, it doesn't even return FALSE if you specify the string 'blow me' as $length. Fuck the what?

And don't even think about giving me the standard bullshit "please double-check the documentation" non-answer that bug report #41395 got on this same issue. I triple-checked the documentation, and nowhere did it say, "Oh, and now it sometimes returns FALSE for no fucking reason. Sit and spin -- we'll break compatibility in sub-point releases whenever we goddamn want."

Reproduce code:
---------------
<?php
var_dump(substr_replace('12345', 'abc', 3));
var_dump(substr_replace('12345', 'abc', 3, 3));
var_dump(substr_replace('12345', 'abc', 3, 4));
var_dump(substr_replace('12345', 'abc', 3, 5));
var_dump(substr_replace('12345', 'abc', 3, 6));

Expected result:
----------------
string(6) "123abc"
string(6) "123abc"
string(6) "123abc"
string(6) "123abc"
string(6) "123abc"

Actual result:
--------------
string(6) "123abc"
string(6) "123abc"
string(6) "123abc"
string(6) "123abc"
bool(false) <-- This shit is broke!

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-07-29 23:32 UTC] jani@php.net 
This "BC break" was caused by a fix for bug #40754 that caused crashes in when passed invalid length. Replacing after position that exceeds the length of the input string is not how it should work, is it? 

Perhaps it should emit a warning about this instead of just return FALSE without telling why it happened..or perhaps it should just silently default to the length of the input string in that case? 

I'm assigning this to Ilia who committed this patch to let him decide how it should be dealt with. I'd just add a big fat E_FATAL error for passing bogus values to the function.. :)

Hint: Next time (hopefully you never have to :) try tone down your tune a bit before clicking the "Submit" button. Insulting the volunteers who develop PHP and occasionally even fix bugs in it is not very constructive and will only cause us to just ignore your report altogether.
 [2007-07-30 01:07 UTC] fznohluwlempsh at mailinator dot com 
I think that how it used to work (minus the memory overflow part) was correct. Despite what either of us think is right, though, 5.2.2 is not the time to be needlessly breaking userland code. Especially not mine. (smiley face)

Thanks, Jani. This bug report may not have read that way, but it was honestly written with love, not hatred, for all PHP contributors. I will be much less of a douche in future correspondence.
 [2007-07-30 14:22 UTC] iliaa@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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC