On Wed, Jun 27, 2012 at 2:19 PM, Nikita Popov wrote:
> I looked at a few other error functions (of which we by the way we
> have *loads*, which is a bad sign) and indeed it seems that they all
> use a separate function to get the error message. Most use a
> xyz_errno() + xyz_error() pair.
>
> So i
On Wed, Jun 27, 2012 at 1:40 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov
> wrote:
>
>>> Why not in the spirit of others have a new function json_last_error_msg() or
>>> something similar?
>>
>> I implemented it with json_last_error(true) returning just a string
hi,
On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov wrote:
>> Why not in the spirit of others have a new function json_last_error_msg() or
>> something similar?
>
> I implemented it with json_last_error(true) returning just a string,
> not an array. You can get the array using array(json_last_erro
On Wed, Jun 27, 2012 at 1:27 PM, Benjamin Eberlei wrote:
>
> On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev
> wrote:
>>
>> Hi!
>>
>> > Makes sense to me. So should I do this? Remove warnings + add string
>> > parameter for json_last_error?
>
>
> I think its weird that the parameter is called $err
On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev wrote:
> Hi!
>
> > Makes sense to me. So should I do this? Remove warnings + add string
> > parameter for json_last_error?
>
I think its weird that the parameter is called $error_string and setting it
to true means returning an array.
Why not in the
Hi!
> Makes sense to me. So should I do this? Remove warnings + add string
> parameter for json_last_error?
Looks fine.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
On Sun, Jun 24, 2012 at 5:39 PM, Rasmus Lerdorf wrote:
> So how about:
>
> mixed json_last_error ( [bool $error_string = false] )
>
> Returns the last error (if any) occurred during the last JSON
> encoding/decoding. By default an integer constant from the table below
> is returned. If $error_stri
On 06/24/2012 05:12 AM, Nikita Popov wrote:
> The main problem with not throwing a warning is that it makes
> debugging the error quite hard. json_last_error() only gives you an
> error code. So you have to use some script like the one used as an
> example in php.net/json_last_error to figure out w
Hola:
On Sat, Jun 23, 2012 at 06:03:34PM -0700, Rasmus Lerdorf wrote:
> And yes, I don't think a warning from json_encode() is useful because to
> properly avoid it you would need an iconv() call before calling it and
> that is pure overhead. Short of that your only recourse is to use @ and
> that
On Sun, Jun 24, 2012 at 12:50 AM, Gustavo Lopes wrote:
> If json_encode() is not supposed to receive badly encoded data, then it's
> the application writer's responsibility to make sure that the data is
> correctly encoded. If, on the other hand, you think that's actually not a
> error on the part
On 06/23/2012 04:06 PM, Stas Malyshev wrote:
> Hi!
>
>> Maybe it is simply time to rethink the error handling.
>
> This is true, current error handling has many deficiencies and is also
> very expensive even when the errors are muted (we still produce the
> whole error string, etc. even if we nev
Hi!
> Maybe it is simply time to rethink the error handling.
This is true, current error handling has many deficiencies and is also
very expensive even when the errors are muted (we still produce the
whole error string, etc. even if we never display it). Unfortunately, BC
concerns prevailed last
On Sun, 2012-06-24 at 00:24 +0200, Nikita Popov wrote:
> Yes, I feel like we must discuss this a thousand times anew. There
> clearly is no consensus about it. Just look at the responses in this
> thread and in other discussions relating this issue. When people read
> "throws a warning, but only if
On Sat, 23 Jun 2012 21:53:01 +0200, Stas Malyshev
wrote:
Hi!
The warning for invalid UTF-8 stays intact and is thrown also with
display_errors = On. If this behavior is undesired this can be remedied
later.
Must we discuss it 1000 times anew? There was a reason why it didn't
throw warning
On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev wrote:
> Hi!
>
>> The warning for invalid UTF-8 stays intact and is thrown also with
>> display_errors = On. If this behavior is undesired this can be remedied
>> later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> throw
On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev wrote:
> Hi!
>
> > The warning for invalid UTF-8 stays intact and is thrown also with
> > display_errors = On. If this behavior is undesired this can be remedied
> > later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> thr
Hi!
> The warning for invalid UTF-8 stays intact and is thrown also with
> display_errors = On. If this behavior is undesired this can be remedied
> later.
Must we discuss it 1000 times anew? There was a reason why it didn't
throw warning when display_errors is on. The reason is that it is very
e
I applied a few changes in
https://github.com/php/php-src/commit/84fe2cc890e49f40bac7c3ba74b3cfc6dc4cef2f
and
https://github.com/php/php-src/commit/36fa17a5fae84ab332366a202f0a709279a2466a.
>From the commit message:
<
json_encode() now returns bool(false) for all possible errors, throws the
r
>
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app and look for that warning to get a really good idea about the
> serv
hi Rasmus,
On Thu, Jun 21, 2012 at 5:33 PM, Rasmus Lerdorf wrote:
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app a
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
wrote:
> Hi Nikita:
>
>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> * A warning is thrown, but only if display_errors=off
>
> So the warning is put into the error log? But only if display_e
On 06/21/2012 07:25 AM, Nikita Popov wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> wrote:
>> Hi Nikita:
>>
>>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>>> string is encountered:
>>> * A warning is thrown, but only if display_errors=off
>>
>> So the wa
On Thu, Jun 21, 2012 at 10:25 PM, Nikita Popov
wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> wrote:
>> Hi Nikita:
>>
>>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>>> string is encountered:
>>> * A warning is thrown, but only if display_errors=off
>>
>
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
wrote:
> Hi Nikita:
>
>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> * A warning is thrown, but only if display_errors=off
>
> So the warning is put into the error log? But only if display_e
Hi Nikita:
> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
> string is encountered:
> * A warning is thrown, but only if display_errors=off
So the warning is put into the error log? But only if display_errors is
off? And if display_errors is on, no warning is produced?
hi,
On Thu, Jun 21, 2012 at 11:21 AM, Nikita Popov
wrote:
>> 5.3 should be brought in line with 5.4.
> So you think that the corrected code should be backed out from PHP 5.3
> and the incorrect 5.4/master behavior be restored?
For the warning yes. For the rest, it should imo return false as wel
On Thu, Jun 21, 2012 at 8:47 AM, Pierre Joye wrote:
>> The reason for this situation is that a patch was applied for all
>> branches, and then reverted, because Stas didn't consider the change
>> towards always throwing a warning (even with display_errors=on)
>> appropriate without further discuss
On Thu, Jun 21, 2012 at 2:47 PM, Pierre Joye wrote:
> hi,
>
> On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
> wrote:
>
>> We currently have a big mess concerning the behavior of json_encode()
>> with incorrectly encoded UTF-8 strings.
>>
>> To summarize the situation:
>>
>> PHP <= 5.3.13, PHP 5.
hi,
On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
wrote:
> We currently have a big mess concerning the behavior of json_encode()
> with incorrectly encoded UTF-8 strings.
>
> To summarize the situation:
>
> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
> string is encou
29 matches
Mail list logo
