Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80378
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CAKxcST_e44EEXj7AuXm0xiXhNmfqjc6uCFRxD4bw6DFycNVy8A@mail.gmail.com>
References: <CAEKnhAFvQpPxkoZKJ-2A-Fjm_ABqxPNMuJoqOsby3ELZgoyQ9g@mail.gmail.com>
	<CAKxcST_e44EEXj7AuXm0xiXhNmfqjc6uCFRxD4bw6DFycNVy8A@mail.gmail.com>
Date: Sun, 11 Jan 2015 20:10:58 +0000
Message-ID: <CAEKnhAHrTYUqxNVrKTUY8snMJ2in6WLZ9YPg2tfcMSns0N-hFw@mail.gmail.com>
To: Paul Dragoonis <dragoonis@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff25238f02ff0050c65fc20
Subject: Re: [PHP-DEV] [RFC] jsond
From: bukka@php.net (Jakub Zelenka)

--e89a8ff25238f02ff0050c65fc20
Content-Type: text/plain; charset=UTF-8

Hi,

On Sun, Jan 11, 2015 at 7:07 PM, Paul Dragoonis <dragoonis@gmail.com> wrote:
>
> I feel if we need to make a minor BC break to get this in, then go with it
> for PHP 7.
>
Yes, it's proposed only for PHP 7 as declared in the RFC


> I do think that if it's possible for you to detect when users supply this
> invalid float input that you would throw an informative exception to help
> people with the transition over to PHP7.
>

Let's first show an example and make clear what the whole thing:
http://3v4l.org/2D72Q

As you can see, the first type (07, 0xff, .1 and -.1) examples are really
inconsistent and give a different results if there are in the array (error)
or as a scalar. This seems like an obvious bug.

The type 2 is consistent. The only problem is that such number format does
not conform to RFC 7159 where the number is specified in
https://tools.ietf.org/html/rfc7159#section-6 :

    number = [ minus ] int [ frac ] [ exp ]
    frac = decimal-point 1*DIGIT

As you can see there is required a digit after decimal point... In this
case we have a non conforming parser which is not right IMHO.

About the special error messages. I could add a new error codes to identify
these problem. However I am not sure that the current json error codes
gives a useful information that would help with migration. I plan to look
on error reporting later and create a different RFC if this one gets in. I
have got an already implementation for bison locations in my testing
scanner and parser ( you can see some logic in
https://github.com/bukka/jso/blob/master/src/jso_parser.y#L160 ) that I
used as an inspiration for jsond. The idea is to provide full reporting
that includes location where the error is (line and column) and possibly
text sample near to the error as well deeper identification of the error.
It's not just this where we can give more info about the cause of the
error. There is still some work and testing that will need to be done
before I propose it however.

Cheers

Jakub

--e89a8ff25238f02ff0050c65fc20--