Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXavZTQu0+tzOJsomNG_PUGoMTxGxB-ZOS8H=DkATPH6+Q@mail.gmail.com>
References: <CAGa2bXYNgjhUWTqzhorcYhd7SEyEvxdhCVWyXr8O-hsZ103E6g@mail.gmail.com>
	<CAGa2bXYBR-=rrifyhWSwB7M1u5J5EL_0o0DcUuFZ9DEuMCrjjQ@mail.gmail.com>
	<CAL+t6cGUJmfhVdSCf3XNn4Mri_fvq-Fuad40yrrKOd8c1uwxXw@mail.gmail.com>
	<CAGa2bXb=mRv2PY880THX_Zd6V8p6pMEWe_+KJ0e1WsKCHskDYA@mail.gmail.com>
	<B4C1DFCC-9849-4B00-9D77-937279C377E1@gmail.com>
	<CAGa2bXavZTQu0+tzOJsomNG_PUGoMTxGxB-ZOS8H=DkATPH6+Q@mail.gmail.com>
Date: Fri, 28 Jun 2013 10:05:21 +0800
Message-ID: <CAHMUw2Hc8Jaz81jeByxF-598r+No26gkBdU=w5Rx3i1XC-GJcg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Sherif Ramadan <theanomaly.is@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf300fb30babdf5e04e02d4fc6
Subject: Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--20cf300fb30babdf5e04e02d4fc6
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 28, 2013 at 9:27 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Tjerk,
>
> 2013/6/27 Tjerk Meesters <tjerk.meesters@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

--20cf300fb30babdf5e04e02d4fc6--