Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68016
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAL+t6cE6DkdOvTAXJJ5xrZeo7UpC+u74R8XP_Y8yDEmP5bFGgQ@mail.gmail.com>
References: <CAGa2bXYNgjhUWTqzhorcYhd7SEyEvxdhCVWyXr8O-hsZ103E6g@mail.gmail.com>
 <CAGa2bXYBR-=rrifyhWSwB7M1u5J5EL_0o0DcUuFZ9DEuMCrjjQ@mail.gmail.com>
 <CAL+t6cGUJmfhVdSCf3XNn4Mri_fvq-Fuad40yrrKOd8c1uwxXw@mail.gmail.com>
 <51CD5580.50103@gmail.com> <CAL+t6cHhTNFcR2JP9PTqhQAOu9rmOvViy2urYeF_QYb0JNg0Vg@mail.gmail.com>
 <CAGa2bXb3Uw=mi3bZ=1fKbknwDXQA8H15Nxny84zDAbWtUTW2TQ@mail.gmail.com> <CAL+t6cE6DkdOvTAXJJ5xrZeo7UpC+u74R8XP_Y8yDEmP5bFGgQ@mail.gmail.com>
Date: Sat, 29 Jun 2013 11:18:19 +0900
Message-ID: <CAGa2bXa-POuAh6UXQ4gTzc71ieZkqkkLa6YDcYs+oDgrEtSaPQ@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: =?ISO-8859-2?Q?Leszek_Krupi=F1ski?= <leafnode@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013d1d5450026c04e0419efc
Subject: Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e013d1d5450026c04e0419efc
Content-Type: text/plain; charset=ISO-8859-1

Hi Sherif,

2013/6/29 Sherif Ramadan <theanomaly.is@gmail.com>

>
> If we tried to fix all of PHP's functions to either return false always or
> return false and raise errors always we'd have to fix every single PHP
> function there is since there's absolutely no consistency there as it is.
>
>
We don't have to change them all. Whether function should raise error or
just return false determined by use case. For instance, raising error in
base64_decode() would be annoying.


> Different functions handle failure differently, and not all functions
> report every possible error they may encounter. Take functions like
> file_get_contents, for example, where it wraps other API functions that
> could RETURN_FAILURE and/or trigger the error handler, and
> file_get_contents isn't even documented to raise those errors in some cases.
>
> I see these as two separate problems. The first problem is clearly a
> design problem (but we can't really do much about that in the short term).
> The second is a documentation problem. Beyond that there are users that
> don't clearly understand the behavior of some functions due to the previous
> two reasons.
>

Third problem. There should be error/exception handling guideline for
developers.


>
>
>> Considering the use case of hex2bin(), it will not handle external inputs
>> in most cases. Therefore, it's better to raise errors invalid inputs. Do
>> you prefer not to raise errors?
>>
>
> Considering the fact that we have a discussion in the bug report mentioned
> earlier (and it was an extensive discussion because not only were our users
> confused but even our core developers were confused if you read the
> responses in that bug report), I would prefer that we leave the function
> the way it is.
>
> The error was added for a very specific reason. People thought it was
> doing what pack('h*', $hex) does, and clearly it wasn't. So the
> documentation was also updated to make note of this and explain it to the
> user, along with the helpful error message to indicate that hex2bin('f')
> would not work.
>

I respect the discussion. However, it does not matter to new comers.
Raising E_WARING for bad length while simply return false for bad hex does
not make sense.


> I don't think there was ever any expectation for the user to do something
> like hex2bin('Hello World') and expect any kind of sensible result. The
> error really does not inform them of anything useful.
>

There is different view for this. Supplying invalid string to hex2bin() is
obvious bug or attack. It would worth to notify users there is obvious
problem.

I didn't want to take vote for such small change. I hope you've convinced.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e013d1d5450026c04e0419efc--