On Fri, Jun 28, 2013 at 9:27 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> Hi Tjerk,
>
> 2013/6/27 Tjerk Meesters <tjerk.meest...@gmail.com>
>
>> The thread started with the assertion that it raises a warning and the
>> commits first remove the warning and then adds it again later, so isn't the
>> whole PR a noop? :)
>
>
> The issue is inconsistent behavior of hex2bin against invalid inputs.
> Both removing and adding E_WARNING provide consistency.
>

I didn't look close enough apparently :)


>
> Adding E_WARNING is better than removing as a result discussion, IMO.
>

Given the sizeable number of functions that don't raise warnings, should
this behaviour then be  extended to those as well, e.g. base64_decode(),
mb_*()?

Of course, doing so puts the onus on the developer to validate their inputs
first to prevent warnings, but personally I feel the gauge on likelihood to
user input exposure conflicts with consistency concerns.


> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.netHi
>



-- 
--
Tjerk

Reply via email to