Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60925
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CAF+90c8=5C_C9wa0q-Tf0OB2vKBow2PH8Nqu5n2SUm=xU1gKgQ@mail.gmail.com>
References: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com>
 <20120621141241.GA25789@analysisandsolutions.com> <CAF+90c8=5C_C9wa0q-Tf0OB2vKBow2PH8Nqu5n2SUm=xU1gKgQ@mail.gmail.com>
Date: Thu, 21 Jun 2012 22:58:56 +0800
Message-ID: <CABBJUpfL=5kk+iBCW9fQRwt20kdR7C8TZsJ17-=VVfmv4uJFMA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@googlemail.com>
Cc: Daniel Convissor <danielc@analysisandsolutions.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: laruence@php.net (Laruence)

On Thu, Jun 21, 2012 at 10:25 PM, Nikita Popov
<nikita.ppv@googlemail.com> wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> <danielc@analysisandsolutions.com> wrote:
>> Hi Nikita:
>>
>>> PHP <=3D 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-=
8
>>> string is encountered:
>>> =C2=A0* A warning is thrown, but only if display_errors=3Doff
>>
>> So the warning is put into the error log? =C2=A0But only if display_erro=
rs is
>> off? =C2=A0And if display_errors is on, no warning is produced?
>>
>> That's very counter-intuitive and un-PHP-like. =C2=A0Someone mentioned i=
t's for
>> security reasons. =C2=A0By that logic, we should get rid of all error
>> messages because they all reveal some information that can be used by
>> attackers.
>
> Yes, I agree with this, but other people thing differently about it ;)
 I think I must missed some infos,  I though you was talking that you
want to generate wanrings without regard of EG(display_errors).

thanks
>
> Personally I'd actually remove the warning completely with the return
> false behavior. The return value makes clear that there was an error
> and json_last_error() can be used to determine what exactly went
> wrong. The warning seems redundant in this case and could actually
> make the use more complicated.
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/