Alexander Valyalkin wrote:
Today I've revised strrchr() function in PHP4.3.7 sources.
It wasn't binary-safe. For example:
1) strrpos('abcd', '') returns 4. Expected FALSE
Although one could argue whether searching for empty
strings makes sense at all the result is not completely
wrong. There *is* an empty string at the end of the haystack ...
So for BC reasons this behavior should not be changed.
2) strrpos("a\0abcde", 'a') returns 6. Expected 2
3) strrpos("a\0bcde", "\0") returns 6. Expected 1
4) strrpos('', '\0') returns 0. Expected FALSE
these actualy look like bugs ...
My version of strrchr() is binary-safe and faster.
Below I provide standalone test with old and new strrpos()
functions. Anyone can compile it and compare results.
Please, *NO MORE STANDALONE TESTS*. Integrate your new implementation,
add a regression test (*.phpt) for it and file a bug on bugs.php.net.
Add a unified diff patch against a PHP release version or against
current CVS.
Wait! *First* write a regression test, then try to fix the code
so that the regression fails with the old implementation and passes
with the new. When not sure about the intended behavior it might be
better to just report a bug and maybe add a regression test.
If the current behavior is there for a reason (like BC issues)
you will find out *before* implementing unneeded stuff.
Chances are *way* higher that someone listens to you ...
If you are very lazy or dont know how compile source file, below
you could see my results of this test:
All (good) programmers are lazy. And all of the subscribers of
this list know how to compile source files. Some even have social
skills. You should start working on yours.
Thank you in advance for your cooperation ...
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
