Fix inconsistency between grapheme_substr() and substr()

[kocsismate]

grapheme_substr("", 0, $length) should return an empty string no matter what integer value $length has. This hasn't been the case before, so let's make this behaviour consistent with substr().

A remaining inconcistency is that while grapheme_substr("abc", strlen("abc"), $length) throws an exception, substr("abc", strlen("abc"), $length) returns "", but substr("abc", strlen("abc") + 1, $length) returns false. It seems to me that substr() is even inconsistent with itself, but it's pretty much probable that I forgot about this change, and the reasoning behind this.

[chschneider]

The scope is much bigger than just grapheme_substr("", 0, ...);

Please revisit all the changes as there are lots of inconsistencies and backward compatibility breaks due to the new exceptions!

[nikic]

I think the real problem is in OUTSIDE_STRING, which should only consider lstart > str_len to be out-of-bounds, not lstart >= str_len. "One past the end" is generally always considered a valid offset (also in strpos etc).

Though this is just a "definitely wrong" check, as this is a grapheme cluster offset, the actual offset check happens later...

[chschneider]

I think even lstart > str_len should be allowed for grapheme_substr() (and probably other functions). Whether it should return "" or false in that case is up for debate but throwing an exception IMHO cripples the API and makes it inconsistent with substr/mb_substr.

[kocsismate]

I'll look into this tonight

[nikic]

I've applied a fix for the main problem in 1312c41 (there are still issues for the non-ASCII case). For the grapheme_substr() case, I would first like to decide on a final behavior for substr(), before we adjust this one (#6182).

[nikic]

Closing this in favor of #6182, which now also implements the update to grapheme_substr().