Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.

I'm sorry, but this is a definite BC break and has bitten me both in Horde code and in my company's codebase. I've re-read the substr docs several times and I don't see any indication that a negative $start can cause substr to return false. Here's the description of the start parameter in its entirety:

If start is non-negative, the returned string will start at the start'th position in string, counting from zero. For instance, in the string 'abcdef', the character at position 0 is 'a', the character at position 2 is 'c', and so forth.

If start is negative, the returned string will start at the start'th character from the end of string.

Example 2454. Using a negative start
<?php
$rest = substr("abcdef", -1);    // returns "f"
$rest = substr("abcdef", -2);    // returns "ef"
$rest = substr("abcdef", -3, 1); // returns "d"

... from http://us3.php.net/substr.

Seems to me as if this was introduced with 5.2.3, not 5.2.2 per the original submitter. Also see http://us.php.net/manual/en/function.substr.php#75999 - this isn't something that only affects me.

"If start is negative, the returned string will start at the start'th
character from the end of string."

The function still accepts a negative start. What changed is if the start is longer than the string length, the test (user friendly version):

 if (from > strlen(str) || (from < 0 && -from > strlen(str)))

As I agree it may break some scripts, the new behavior should be documented, as a bug fix.

Can we move this bug to the doc category?

Reclassified.

Okay, documenting it at least makes code and documentation consistent, but why the change in the first place? Why not avoid the break and leave it consistent?

Don't you think such questions should have been asked during RC stage?
It's a bit too late to change it back, what's done is done.

Yes, of course it should have been caught in the RC stage, but it wasn't - in fact it took me more than one final release to track it down.

Why is what's done, done, when the behavior that was changed existed for years and years, and the new behavior has been around for 2 point releases?

I don't think it's good idea to change it in every release back and forth.
Also the current behavior makes much more sense to me.
Negative string length is a nonsense, so false is the correct result.

Alright, here's the use case:

I have a string. I want at most 16 characters of it. For all PHP versions before 5.2.[2 or 3], I could do this:

$shorter = substr($string, -16);

Now I have to do this:

if (strlen($string) > 16))
    $shorter = substr($string, -16);
else
    $shorter = $string;


My question is, especially since I'm asking that the historical behavior of PHP be maintained, how does this change improve the language? What is the point of it?

>if (strlen($string) > 16))
>    $shorter = substr($string, -16);
>else
>    $shorter = $string;

$shorter = substr($string, 0, 16);
Please don't tell me you didn't know that.

I should have specified that sometimes you only want the last X characters of a string. That's what this is about.

As far as I can tell, this has been documented since at least 2002. The fact that it worked up until 5.2.1 doesn't mean that you should have used it.

From the docs:
"""If string is less than or equal to start characters long, FALSE  will be returned."""

http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/strings/functions/substr.xml?revision=1.1&view=markup

S

Ah. I do see that now, but it's in the docs for when $length is given and is positive. I guess the default for $length is presumed to be positive? This should definitely be documented under the $start parameter, not $length. And so I think it's a stretch to say this has been documented.

If this was never *supposed* to work then I can see it's a documentation problem and will let it go.