Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXb3Uw=mi3bZ=1fKbknwDXQA8H15Nxny84zDAbWtUTW2TQ@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>
Date: Fri, 28 Jun 2013 21:54:27 -0400
Message-ID: <CAL+t6cE6DkdOvTAXJJ5xrZeo7UpC+u74R8XP_Y8yDEmP5bFGgQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: =?ISO-8859-2?Q?Leszek_Krupi=F1ski?= <leafnode@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f3b9fdd8c753904e04146b9
Subject: Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
From: theanomaly.is@gmail.com (Sherif Ramadan)

--e89a8f3b9fdd8c753904e04146b9
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 28, 2013 at 9:41 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Sherif,
>
> The problem is that current code 'returns false for invalid hex' while it
> 'returns false and E_WARNING for invalid length'.
>
> We may choose behavior for invalid inputs
>  - return false always
>  - return false and raise E_WARNING always
>
> Mixing them up is not good, especially in the same function. IMHO. PHP has
> enough inconsistency. We should try to remove inconsistency much as
> possible. Besides the change will not break code as long as it is used as
> it should be.
>
>
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.

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.


> 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
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.

</my $0.000002>


>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
>

--e89a8f3b9fdd8c753904e04146b9--