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