# What gruntwork needs to be done - Thread: https://externals.io/message/47806 - Original archive: https://news-web.php.net/php.internals/47806 - Started by Justin Dearing on 2010-04-06T17:08:45+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47806 — Justin Dearing — 2010-04-06T17:08:45+00:00 URL: https://externals.io/message/47806#47806 Hi, So pending review an acceptance by Dmitry, I've written my first patch for PHP. While there is a good chance I will need to make further revisions to the test or code, I don't know what that is. However, I've got some free time at the moment, and I'd like to make use of some of the sunk costs of figuring out how to hack PHP. So I know that in general there is a lot of work to be done. I also know that there are plenty of open bugs, tests to be written, etc etc. What I am looking for is someone to say is "here are the next 10 bugs I will work on can you write me test" or "I wrote this patch on linux, I need someone to make it work on windows too" or, "Party X complains of this but refuses to fill out a proper bug report." Justin --- ## #47808 — Rasmus Lerdorf — 2010-04-06T17:34:44+00:00 URL: https://externals.io/message/47806#47808 · In reply to: #47806 > So pending review an acceptance by Dmitry, I've written my first patch for > PHP. While there is a good chance I will need to make further revisions to > the test or code, I don't know what that is. > > However, I've got some free time at the moment, and I'd like to make use of > some of the sunk costs of figuring out how to hack PHP. So I know that in > general there is a lot of work to be done. I also know that there are > plenty of open bugs, tests to be written, etc etc. What I am looking for is > someone to say is "here are the next 10 bugs I will work on can you write me > test" or "I wrote this patch on linux, I need someone to make it work on > windows too" or, "Party X complains of this but refuses to fill out a proper > bug report." Here is a straightforward (but not easy) one: http://bugs.php.net/bug.php?id=47435 The php_filter_validate_ip() function in ext/filter/logical_filters.c needs those reserved IPV6 ranges added to the FORMAT_IPV6 case in the switch statement there when `FILTER_FLAG_NO_RES_RANGE` is set. I say it isn't super easy because we don't have much in the way of ipv6 parsing in PHP yet, so it will probably involve finding some decent code that can expand an ipv6 notation into something we can logically separate. That might also mean a rewrite of the _php_filter_validate_ipv6() function in the same file. Another one, if you are interested in encoding issues: http://bugs.php.net/bug.php?id=49687 I don't necessarily agree with Scott that it is wrong to expect `addslashes()` to validate the input string. It could call get_next_char() the same way php_escape_html_entities_ex() in ext/standard/html.c does. And we need that `utf8_decode()` fix mentioned in the report reviewed/committed if it hasn't been already. -Rasmus --- ## #47810 — Scott MacVicar — 2010-04-06T17:47:44+00:00 URL: https://externals.io/message/47806#47810 · In reply to: #47808 > > > […] > > Here is a straightforward (but not easy) one: > > http://bugs.php.net/bug.php?id=47435 > > The php_filter_validate_ip() function in ext/filter/logical_filters.c > needs those reserved IPV6 ranges added to the FORMAT_IPV6 case in the > switch statement there when `FILTER_FLAG_NO_RES_RANGE` is set. I say it > isn't super easy because we don't have much in the way of ipv6 parsing > in PHP yet, so it will probably involve finding some decent code that > can expand an ipv6 notation into something we can logically separate. > That might also mean a rewrite of the _php_filter_validate_ipv6() > function in the same file. > > Another one, if you are interested in encoding issues: > > http://bugs.php.net/bug.php?id=49687 > > I don't necessarily agree with Scott that it is wrong to expect > `addslashes()` to validate the input string. It could call > get_next_char() the same way php_escape_html_entities_ex() in > ext/standard/html.c does. And we need that `utf8_decode()` fix mentioned > in the report reviewed/committed if it hasn't been already. > I fixed utf8_decode and I had a patch for adding utf8_validate which is probably suitable for 5.4. http://whisky.macvicar.net/patches/utf8-string.diff.txt It's not quite done, I had intentions of adding support for using truncate, simple true / false for valid or the unicode replacement character. Scott --- ## #47811 — Rasmus Lerdorf — 2010-04-06T17:54:54+00:00 URL: https://externals.io/message/47806#47811 · In reply to: #47810 > > > > […] > > I fixed utf8_decode and I had a patch for adding utf8_validate which is probably suitable for 5.4. > > http://whisky.macvicar.net/patches/utf8-string.diff.txt > > It's not quite done, I had intentions of adding support for using truncate, simple true / false for valid or the unicode replacement character. My only issue with this is that it essentially duplicates the utf8 part of get_next_char() from html.c. I'd like to see cs parsing in one place instead of spread out all over the code tree. The get_next_char() function also supports other charsets, so we could have a more generic cs_validate() function along with utf8_validate(). -Rasmus --- ## #47812 — Scott MacVicar — 2010-04-06T18:03:41+00:00 URL: https://externals.io/message/47806#47812 · In reply to: #47811 > > > […] > > My only issue with this is that it essentially duplicates the utf8 part > of get_next_char() from html.c. I'd like to see cs parsing in one place > instead of spread out all over the code tree. The get_next_char() > function also supports other charsets, so we could have a more generic > cs_validate() function along with utf8_validate(). > I missed this function last year, abstracting that and making it PHPAPI would be awesome. Scott --- ## #47813 — Martin Jansen — 2010-04-07T06:15:24+00:00 URL: https://externals.io/message/47806#47813 · In reply to: #47811 > > > […] > > My only issue with this is that it essentially duplicates the utf8 part > of get_next_char() from html.c. I'd like to see cs parsing in one place > instead of spread out all over the code tree. The get_next_char() > function also supports other charsets, so we could have a more generic > cs_validate() function along with utf8_validate(). Shouldn't this be str_cs_validate() then? Or has the plan been abandoned to group functions into logical groups by their prefix? - Martin