On Fri, Jun 28, 2013 at 9:27 AM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Tjerk,
>
> 2013/6/27 Tjerk Meesters <[email protected]>
>
>> 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
> [email protected]
>
--
--
Tjerk