Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[David Gebler]

Juan,
You can always offer two votes on the RFC - one for the function itself,
then one for should it return boolean or return an int representing the
json_last_error constants and let it be decided that way.

I think on the whole, I agree with the sentiment that returning boolean and
checking json_last_error() on false is probably the best / least worst
option.

So if I could vote, I would vote yes and for the boolean option, with a
secondary preference for returning int if boolean option is rejected.

And I was unconvinced about the whole idea originally, so a good example of
where positive, robust discussion can change someone's mind.

Good luck with progressing the RFC, I don't think I have anything else to
add.


On Sat, Aug 27, 2022 at 12:46 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:

> OMG, I need to take a rest, sorry for this, here it goes again; the
> about JSON_INVALID_UTF8_IGNORE opinion is the same, but previous code
> was wrong
>
> Code:
>
> 
> var_dump(json_decode("{ \"a\xb0b\" : \"dummy\" }", true, 512),
> json_last_error_msg());
> var_dump("");
> var_dump(json_decode("{ \"a\xb0b\" : \"dummy\" }", true, 512,
> JSON_INVALID_UTF8_IGNORE), json_last_error_msg());
>
> Result:
>
> NULL
> string(56) "Malformed UTF-8 characters, possibly incorrectly encoded"
> string(12) ""
> array(1) { ["ab"]=> string(5) "dummy" }
> string(8) "No error"
>
> Saying so, now ... yes I support and think is NEEDED the usage of the
> JSON_INVALID_UTF8_IGNORE , as json_validate() result goes in the same
> direction with json_decode(). I think we need to have this flag.
>
> RFC: https://wiki.php.net/rfc/json_validate
> Implementation: https://github.com/php/php-src/pull/9399
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

OMG, I need to take a rest, sorry for this, here it goes again; the
about JSON_INVALID_UTF8_IGNORE opinion is the same, but previous code
was wrong

Code:

 string(5) "dummy" }
string(8) "No error"

Saying so, now ... yes I support and think is NEEDED the usage of the
JSON_INVALID_UTF8_IGNORE , as json_validate() result goes in the same
direction with json_decode(). I think we need to have this flag.

RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El sáb, 27 ago 2022 a las 1:31, juan carlos morales
() escribió:
>
> === Open issues/concerns ===
>
>
> @@@ Usage of JSON_INVALID_UTF8_IGNORE @@@
>
> - I have my doubts now, because of this codes:
>
> ```
> 
> var_dump(json_validate("\"a\xb0b\""), json_last_error_msg());
> var_dump("");
> var_dump(json_validate("\"a\xb0b\"", 512, JSON_INVALID_UTF8_IGNORE),
> json_last_error_msg());
> ```
>
> Results:
>
> bool(false)
> string(56) "Malformed UTF-8 characters, possibly incorrectly encoded"
> string(12) ""
> bool(true)
> string(8) "No error"
>
>
> Gives different results, but ...
>
> ```
> 
> var_dump(json_decode("{ \"a\xb0b\" : \"dummy\" }"), json_last_error_msg());
> var_dump("");
> var_dump(json_decode("{ \"a\xb0b\" : \"dummy\" }", 512,
> JSON_INVALID_UTF8_IGNORE), json_last_error_msg());
> ```
>
> Results in:
> NULL
> string(56) "Malformed UTF-8 characters, possibly incorrectly encoded"
> string(12) ""
> NULL
> string(56) "Malformed UTF-8 characters, possibly incorrectly encoded"
>
>
>
> So at a first look, seems the flag should also be remove, as with
> json_validate() we say its valid, but then on json_decode() we get
> NULL, even with the JSON_INVALID_UTF8_IGNORE provided; does not make
> sense I believe.
>
> What do you think? Is there a use case I am missing here? Is this flag
> worth to have still?
>

I made a huge mistake sorry, long day here, 1:30 am , the code for
json_decode should be as:

var_dump(json_decode("{ \"a\xb0b\" : \"dummy\" }"), true, 512,
json_last_error_msg());
var_dump("");
var_dump(json_decode("{ \"a\xb0b\" : \"dummy\" }", true, 512,
JSON_INVALID_UTF8_IGNORE), json_last_error_msg());

Resulting in

NULL
bool(true)
int(512)
string(56) "Malformed UTF-8 characters, possibly incorrectly encoded"
string(12)""
array(1) { ["ab"]=> string(5) "dummy" }
string(8) "No error"


Saying so, now ... yes I support the usage of the
JSON_INVALID_UTF8_IGNORE , as json_validate() result goes in the same
direction with json_decode(). I think we need to have this flag.

RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

I now provide an update of the discussion.

The good, the bads, the open questions, etc.

All of this will go into the RFC also, as requested by the procedure
in https://wiki.php.net/rfc/howto

"Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions. Cover both
the positive and negative arguments. Put the RFC URL into all your
replies."

=== UPDATES ===

- Different users have tested the functionality and obtained the
promissed results. Also their feedback about it was positive.

- Most part of the community in the mailing list showed a positive
opinion about this RFC, and looks forward for its integration into
PHP.

- The ones that checked the code also agree that is small
implementation, easy to mantain, and at the same time provides a big
benefit for such small implementation.

- The community got involve very actively in the discussion of the RFC
and provided all kind of useful feedback, and also took the time to
test json_validate() by themselves.


=== Bad reasons for json_validate() provided by the community ===


- One member of the mailing list expressed that:

1) Incorporating such a small implementation that can be achieve with
userland code is not a good idea.

Quote: "If we keep the tendency to pollute already bloated standard
library with an army of small functions that could have not exists and
be replaced with normal PHP counterparts IMHO we'll end with
frustration from developers as I believe DX slowly falls down here."

2) json_validate() would only be useful for edge cases.

Quote: "A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles
1% of use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the next PhpToken::validate.
All above can be valid if we trust that people normally validate 300MB
payloads to do nothing if they DON'T fail and there is nothing strange
about that."

3) The user also provided an implementation of a JSON parser written
in pure PHP. https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc


=== Good reasons for json_validate() provided by the community ===


@@@ Use cases provided by some members, I quote:

- "Yes well-formed JSON from a trusted source tends to be small-ish.
But a validation function also needs to deal with non-well-formed
JSON, otherwise you would not need to validate it."

- "If with a new function (json_validate()) it becomes much easier to
defend against a Denial-of-Service attack for some parts of a JSON
API, then this can be a good addition just for security reasons."

- "fast / efficient validation of a common communication format
reduces the attack surface for Denial-of-Service attacks."

@@@ Memory usage

- During the test of json_validate() from some users, they were happy
about the memory usage that was zero in most cases (which is the main
benefit out this feature).
Someone also did a test with a very large string (75 MB) and only a
few bytes were needed as reported by him; also the same user reported
an execution speed improvement by a 20-25% over using json_decode().

@@@ Reasons not to depend on userland JSON parsers

Even possible to write an excellent JSON parser in PHP like one of the
members in the mailing list provided us, there are good reasons for
dont relying on userland solutions.

# 1 - User Tim Düsterhus provided nice thoughts about this, in favor
to json_validate(), ... I quote him:

- "Writing a JSON parser is non-trivial as evidenced by:
https://github.com/nst/JSONTestSuite. I expect userland
implementations to be subtly buggy in edge cases. The JSON parser in
PHP 7.0+ is
certainly more battle-tested and in fact it appears to pass all of the
tests in the linked test suite."

- "Even if the userland implementation is written very carefully, it
might behave differently than the native implementation used by
json_decode() (e.g. because the latter is buggy for some reason or
because the correct behavior is undefined). This would imply that an
input string that was successfully validated by your userland parser
might ultimately fail to parse when passed to json_decode(). This is
exactly what you don't want to happen."


(Some other members including me, also share this opinion.)


# 2 - The JSON parser in PHP follows an special convention, marked in
the PHP documentation.

# 3 - We already have a JSON parser in PHP, that is used by
json_decode(); reusing the existing JSON Parser provides 100%
compatibility between the validation of a json-string, and the
decoding of it.

# 4 - The user Larry Gafield also provided good reason to integrate
this implementation into PHP. I quote him:

"The heuristic I use is that an API should be "reasonably complete" in
one location.  Having a half-assed API in C and the rest left to
inconsistent and redundant user-space implementations is a terrible
API; the same would apply for a user-space 

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Larry Garfield]

On Fri, Aug 26, 2022, at 1:41 PM, Ayesh Karunaratne wrote:
>> whether returning boolean is the right thing to do at all. It seems obviously
>> intuitive it should, returning true for valid and false for invalid JSON
>> but then if you consider you're still going to be in the situation of
>> calling json_last_error() if you want to know why invalid JSON was invalid
>> and in particular you might not expect the "last error" to have changed
>> just from an attempt to check a string. How can there be an error when by
>> definition you weren't trying to do anything except check the validity of
>> some unknown data? Not sure what the answer is there...curious what other
>> people's views are on that. I don't think throwing an exception on invalid
>> JSON is the right answer in any case.
>
> One of the reasons why I like `json_validate` over `is_json` is that
> the former does not imply a boolean return value as strongly as the
> latter.
>
> I think we should not modify any state with the `json_validate`
> function, and I'd be happy with the function returning 0 for a valid
> JSON, or the error code as an integer (`JSON_ERROR_STATE_MISMATCH`,
> `JSON_ERROR_SYNTAX`, etc.). `JSON_ERROR_NONE` constant is already
> assigned 0, so they align quite well too.

The problem here is that you're using a falsy return (0) to indicate "it 
validated", which is logically true.  PHP's type juggling makes that a very bad 
idea.

I somehow doubt it will get much traction, but this is the sort of case where a 
"naked either" approach could work well: 
https://peakd.com/hive-168588/@crell/much-ado-about-null

Though there's also the risk then of all objects being "truthy", since there 
seems to be no appetite for a __toBool() method as that's been shot down 
before.  At some point, we need to realize that our current design philosophy 
boxes us in on too many sides and something is going to have to change.

I see the argument for json_last_error() not being a great fit, but given the 
limitations we've chosen to have in the language it seems like "return bool and 
use json_last_error()" is the least-bad option.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] What type of Exception to use for unserialize() failure?

[Rowan Tommins]

On 25 August 2022 16:06:48 BST, "Tim Düsterhus" wrote:

>- I've noticed that 'unserialize()' already emits E_WARNING for some types of 
>error (e.g. out-of-bounds integers), so users already need to be prepared for 
>E_WARNING to be emitted. I've adjusted the aforementioned Notice to Warning, 
>but we might be able to directly jump to UnserializationFailedException from 
>the existing warnings?


IMHO, any change from Warning or lower to Exception or Error is a clear 
Breaking Change, because it can make a program that runs successfully under one 
version abort mid-process in another.

So, while it probably makes sense for all serialisation errors to consistently 
throw, that should be planned for 9.0, and everything that's not already an 
exception could raise a consistently formatted E_WARNING in 8.3.

Regards,

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Derick Rethans]

On 26 August 2022 18:28:59 BST, Kamil Tekiela  wrote:
>What is the reasoning behind the name? I can't find it explained in the
>RFC. What about other alternatives like is_json or validate_json?

It's part of the json extension so it should start with json_ following naming 
guidelines for functions in extensions.

cheers
Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Ayesh Karunaratne]

> whether returning boolean is the right thing to do at all. It seems obviously
> intuitive it should, returning true for valid and false for invalid JSON
> but then if you consider you're still going to be in the situation of
> calling json_last_error() if you want to know why invalid JSON was invalid
> and in particular you might not expect the "last error" to have changed
> just from an attempt to check a string. How can there be an error when by
> definition you weren't trying to do anything except check the validity of
> some unknown data? Not sure what the answer is there...curious what other
> people's views are on that. I don't think throwing an exception on invalid
> JSON is the right answer in any case.

One of the reasons why I like `json_validate` over `is_json` is that
the former does not imply a boolean return value as strongly as the
latter.

I think we should not modify any state with the `json_validate`
function, and I'd be happy with the function returning 0 for a valid
JSON, or the error code as an integer (`JSON_ERROR_STATE_MISMATCH`,
`JSON_ERROR_SYNTAX`, etc.). `JSON_ERROR_NONE` constant is already
assigned 0, so they align quite well too.

As for exceptions, I too think throwing an exception here is an
anti-pattern. It makes perfect sense to throw on `json_decode` if the
program doesn't want to deal with invalid JSON gracefully. But calling
`json_validate` is an intended call, and returning an error is
excepted, and not an exception.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[David Gebler]

On Fri, Aug 26, 2022 at 6:29 PM Kamil Tekiela  wrote:

> What is the reasoning behind the name? I can't find it explained in the
> RFC. What about other alternatives like is_json or validate_json?
>

The name json_validate makes most sense to me; it groups itself together
nicely with the other json_* API functions. I think is_json is what was
originally proposed but besides being then inconsistent with the rest of
the JSON API function naming, consider most of the is_* functions are for
checking types (and some for file properties), not validation.

But on the function, the other question which remains for me is whether
returning boolean is the right thing to do at all. It seems obviously
intuitive it should, returning true for valid and false for invalid JSON
but then if you consider you're still going to be in the situation of
calling json_last_error() if you want to know why invalid JSON was invalid
and in particular you might not expect the "last error" to have changed
just from an attempt to check a string. How can there be an error when by
definition you weren't trying to do anything except check the validity of
some unknown data? Not sure what the answer is there...curious what other
people's views are on that. I don't think throwing an exception on invalid
JSON is the right answer in any case.

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Kamil Tekiela]

What is the reasoning behind the name? I can't find it explained in the
RFC. What about other alternatives like is_json or validate_json?

Re: [PHP-DEV] ksort breaking change

[Sara Golemon]

On Fri, Aug 26, 2022 at 11:53 AM Christian Schneider 
wrote:

> Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> > What I can see is two noble, but conflicting ideals:
> > 1/ sort() and ksort() should be consistent about their sorting
> algorithms.
> > I think we can all agree about that in the ideal case, at least.
> > 2/ Behavior within a minor release should be self-consistent and
> > predictable.
> >
> > Given the above, my initial inclination is to err on the side of
> > conservatism for 8.0.x at the least (we're nearly at the end of our
> primary
> > bug-fix cycle anyway) by reverting the fix on our branch.
> > For 8.1, I think we have a more difficult decision to make with over a
> year
> > of bug-fix releases to go, and I might be swayed to keep the fix around
> > there.
>
> I agree with the description of the ideals but I'm not sure why you think
> the resolution should be different of 8.0 than 8.1.
>
> We already transitioned our existing code base from 8.0 to 8.1, including
> testing for changes due to the way numeric string are handled. I think it
> is reasonable to adapt it for 8.2 (where another round of breaking changes
> will have to be tested anyway) but I would not expect to having to do this
> for a bug-fix release 8.1.x.
>
> That's why I'd rather have this change postponed to 8.2 (which is not that
> far off anyway).
>
>
Honestly, I vacillated on this one for awhile, having started from a "we
should really revert on 8.1 as well".  I flipped when I decided that the
breakage potential was honestly very small.  That said, no real complaints
either way.

-Sara

Re: [PHP-DEV] ksort breaking change

[Christian Schneider]

Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> What I can see is two noble, but conflicting ideals:
> 1/ sort() and ksort() should be consistent about their sorting algorithms.
> I think we can all agree about that in the ideal case, at least.
> 2/ Behavior within a minor release should be self-consistent and
> predictable.
> 
> Given the above, my initial inclination is to err on the side of
> conservatism for 8.0.x at the least (we're nearly at the end of our primary
> bug-fix cycle anyway) by reverting the fix on our branch.
> For 8.1, I think we have a more difficult decision to make with over a year
> of bug-fix releases to go, and I might be swayed to keep the fix around
> there.

I agree with the description of the ideals but I'm not sure why you think the 
resolution should be different of 8.0 than 8.1.

We already transitioned our existing code base from 8.0 to 8.1, including 
testing for changes due to the way numeric string are handled. I think it is 
reasonable to adapt it for 8.2 (where another round of breaking changes will 
have to be tested anyway) but I would not expect to having to do this for a 
bug-fix release 8.1.x.

That's why I'd rather have this change postponed to 8.2 (which is not that far 
off anyway).

Regards,
- Chris

[PHP-DEV] Re: ksort breaking change

[Sara Golemon]

On Fri, Aug 26, 2022 at 7:19 AM Christoph M. Becker 
wrote:
>
> On 26.08.2022 at 05:15, Go Kudo wrote:
>
> > In the actively supported version of PHP, `ksort()` has been modified to
> > include BC Break.
> >
> > https://github.com/php/php-src/issues/9296
> >
> > This may seem like an appropriate bug fix, but it is a clear BC Break. I
> > think this change should only be introduced in PHP 8.2 and later.
>
> In this case, the functions didn't behave as documented, namely to
> conform to the general conversion rules, which had a relevant change in
> PHP 8.0.  Apparently, this case has been overlooked when the change had
> been implemented, and only been noticed recently (what still surprises
> me).  Anyway, fixing the issue now is not really introducing a BC break,
> since code relying on the previous behavior did not conform to the
> documentation.
>

What I can see is two noble, but conflicting ideals:
1/ sort() and ksort() should be consistent about their sorting algorithms.
I think we can all agree about that in the ideal case, at least.
2/ Behavior within a minor release should be self-consistent and
predictable.

Knowing the discrepancy exists in current releases of 8.0.x and 8.1.x,
we're currently in a position where ideal #2 is satisfied, but ideal #1 is
failing in a small, and subtle way.  The potential consequence of this is
sites out there where the inconsistency shows through to end users (though
I wouldn't actually expect any breakages as a result, just clowniness).

With the recently applied patch, we would resolve ideal #1, but we would do
so at the cost of ideal #2.  It's doubtful this will actually break any
code either, but potentially user-facing affects could be visible,
especially in a mixed-version environment (such as during a rolling
upgrade).

Given the above, my initial inclination is to err on the side of
conservatism for 8.0.x at the least (we're nearly at the end of our primary
bug-fix cycle anyway) by reverting the fix on our branch.
For 8.1, I think we have a more difficult decision to make with over a year
of bug-fix releases to go, and I might be swayed to keep the fix around
there.

> > Fortunately, there is not yet a release in each version that
incorporates
> > this change. I think it is possible to revert now.
>
> Well, the fix is part of the currents RCs; that doesn't make it
> impossible to revert, but RMs should have a say in that.  Thus I'm
> adding Sara and Gabriel as recepients.
>

Don't forget Ben and Patrick as well, this impacts 8.1 equally.

-Sara

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Larry Garfield]

On Fri, Aug 26, 2022, at 4:00 AM, Michał Marcin Brzuchalski wrote:

> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of
> use cases, somebody will raise another RFC
> for simplexml_validate_string or yaml_validate and the next
> PhpToken::validate.

The heuristic I use is that an API should be "reasonably complete" in one 
location.  Having a half-assed API in C and the rest left to inconsistent and 
redundant user-space implementations is a terrible API; the same would apply 
for a user-space library that is half-assed and leaves the rest to "someone 
else to write."  Naturally "reasonably complete" is a somewhat squishy term, 
which is why it's a heuristic.

By that metric, yes, str_starts_with() and friends absolutely belonged in core, 
because we already have a bunch of string functions and str_starts_with() is by 
a wide margin the most common usage of strpos().

By the same token, yes, json_validate() makes sense to include in the main API, 
which means in C.  If there's a performance benefit to doing so as well, that 
makes it an easy sell for me.

simplexml_validate_string: I could see the argument there as well, quite 
frankly.  Unless there is already an equivalently capable option in core, which 
in this case it sounds like there is.

yaml_validate: There is no YAML parser that ships with PHP, so no, this 
wouldn't make sense.  If at some point in the future PHP added a C-based YAML 
extension to the standard distribution, then including a validate function in 
that would make sense.  (Whether we should include a YAML extension in the 
standard distribution is an entirely separate question.)

PHPToken::validate: Again, PHPToken is in core, so why wouldn't we also include 
a validate for it, especially if it's easy to do and logically belongs in the 
same "surface area"?

Really, the whole "functions don't belong in C" argument is tired.  That ship 
sailed decades ago.  PHP has a mixed-implementation life, whether we like it or 
not.  Some APIs and standard lib components are in C, deal.  For those that are 
or make sense to be, they should be robust and self-contained and complete.  
For those that aren't, they should be kept out as a set, or added "as a set."  
That's the granularity where we should be talking, not the function level.

I'm in favor of this RFC.  However, I do agree that it should never throw, 
period.  Only return a boolean.  I'm not sure if JSON_INVALID_UTF8_IGNORE makes 
sense either, frankly.  That should get corrected before it goes to a vote.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ksort breaking change

[juan carlos morales]

Oh! My bad. Nice work! Cheers

El vie., 26 de agosto de 2022 16:51, Tim Düsterhus 
escribió:

> Hi
>
> On 8/26/22 16:15, juan carlos morales wrote:
> > Seems like we Don't Have tests for the function or we should enhance the
> > existing ones. If We would Have proper tests the FIX would break it (as I
> > Don't see tests in the fix itself).That is why I say so.
> >
>
> Various tests were adjusted in:
> https://github.com/php/php-src/pull/9293/files
>
> Best regards
> Tim Düsterhus
>

Re: [PHP-DEV] ksort breaking change

[Tim Düsterhus]

Hi

On 8/26/22 16:15, juan carlos morales wrote:

Seems like we Don't Have tests for the function or we should enhance the
existing ones. If We would Have proper tests the FIX would break it (as I
Don't see tests in the fix itself).That is why I say so.



Various tests were adjusted in: 
https://github.com/php/php-src/pull/9293/files


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

RE: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Jeffrey Dafoe]

> -Original Message-
> From: juan carlos morales 
> Sent: Thursday, August 25, 2022 12:02 PM
> To: PHP Internals List 
> Subject: [PHP-DEV] RFC json_validate() - status: Under Discussion
> 
> Hello.
> 
> I am glad to present to you the RFC for json_validate() function.
> 
> The code/implementation still needs some workout, but seems to be fine
> enough to be presented to you all.
> 
> I look forward for feedback
> 
> Thanks in advance.
> 
> Juan.
> 
> RFC: https://wiki.php.net/rfc/json_validate
> 
> Implementation: https://github.com/php/php-src/pull/9399

Not a voting member, but I'd like to voice support for this. JSON is widely 
used, core already supports this functionality, the scope of change is minimal, 
and the feature is useful.

-Jeff

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ksort breaking change

[juan carlos morales]

Seems like we Don't Have tests for the function or we should enhance the
existing ones. If We would Have proper tests the FIX would break it (as I
Don't see tests in the fix itself).That is why I say so.

I Am not in my computer atm. I Will check this later

El vie., 26 de agosto de 2022 15:01, Christian Schneider <
cschn...@cschneid.com> escribió:

> Am 26.08.2022 um 14:19 schrieb Christoph M. Becker :
> > On 26.08.2022 at 05:15, Go Kudo wrote:
> >
> >> In the actively supported version of PHP, `ksort()` has been modified to
> >> include BC Break.
> >>
> >> https://github.com/php/php-src/issues/9296
> >>
> >> This may seem like an appropriate bug fix, but it is a clear BC Break. I
> >> think this change should only be introduced in PHP 8.2 and later.
> >
> > In this case, the functions didn't behave as documented, namely to
> > conform to the general conversion rules, which had a relevant change in
> > PHP 8.0.  Apparently, this case has been overlooked when the change had
> > been implemented, and only been noticed recently (what still surprises
> > me).  Anyway, fixing the issue now is not really introducing a BC break,
> > since code relying on the previous behavior did not conform to the
> > documentation.
>
>
> I don't really agree with your definition of BC break.
>
> The behavior of the function with a mix of numeric/non-numeric string keys
> changes from 8.1.9 to 8.1.10 which in my world qualifies as a BC break.
>
> Regards,
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] ksort breaking change

[Christian Schneider]

Am 26.08.2022 um 14:19 schrieb Christoph M. Becker :
> On 26.08.2022 at 05:15, Go Kudo wrote:
> 
>> In the actively supported version of PHP, `ksort()` has been modified to
>> include BC Break.
>> 
>> https://github.com/php/php-src/issues/9296
>> 
>> This may seem like an appropriate bug fix, but it is a clear BC Break. I
>> think this change should only be introduced in PHP 8.2 and later.
> 
> In this case, the functions didn't behave as documented, namely to
> conform to the general conversion rules, which had a relevant change in
> PHP 8.0.  Apparently, this case has been overlooked when the change had
> been implemented, and only been noticed recently (what still surprises
> me).  Anyway, fixing the issue now is not really introducing a BC break,
> since code relying on the previous behavior did not conform to the
> documentation.


I don't really agree with your definition of BC break.

The behavior of the function with a mix of numeric/non-numeric string keys 
changes from 8.1.9 to 8.1.10 which in my world qualifies as a BC break.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for floored division and modulo functions

[Christoph M. Becker]

On 26.08.2022 at 01:29, Larry Garfield wrote:

> On Thu, Aug 25, 2022, at 3:16 PM, Rowan Tommins wrote:
>
>> But then we face the awkward asymmetry of the current functionality:
>>
>> intdiv() - Integer division
>> / - Floating-point division
>> % - Integer modulus
>> fmod() - Floating-point modulo
>>
>> Apparently as of PHP 8.0, there is also an fdiv() function, but the
>> manual doesn't currently explain why it exists, and whether it will
>> always give the same result as / (and if not, why not?)
>
> / in PHP 8.0+ throws DivideByZeroError if you divide by 0.  Prior versions, 
> it was a fatal error.
>
> fdiv() returns a NAN or INF constant for division by 0.
>
> echo fdiv(5, 0); // INF
> echo fdiv(-5, 0); // -INF
> echo fdiv(0, 0); // NAN

There is another (minor?) difference, namely that the / operator
evaluates to an int, if the numbers are evenly divisible, but fdiv()
always returns a float ().

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: ksort breaking change

[Christoph M. Becker]

On 26.08.2022 at 05:15, Go Kudo wrote:

> In the actively supported version of PHP, `ksort()` has been modified to
> include BC Break.
>
> https://github.com/php/php-src/issues/9296
>
> This may seem like an appropriate bug fix, but it is a clear BC Break. I
> think this change should only be introduced in PHP 8.2 and later.

In this case, the functions didn't behave as documented, namely to
conform to the general conversion rules, which had a relevant change in
PHP 8.0.  Apparently, this case has been overlooked when the change had
been implemented, and only been noticed recently (what still surprises
me).  Anyway, fixing the issue now is not really introducing a BC break,
since code relying on the previous behavior did not conform to the
documentation.

> Fortunately, there is not yet a release in each version that incorporates
> this change. I think it is possible to revert now.

Well, the fix is part of the currents RCs; that doesn't make it
impossible to revert, but RMs should have a say in that.  Thus I'm
adding Sara and Gabriel as recepients.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie., 26 de agosto de 2022 13:08, juan carlos morales <
dev.juan.mora...@gmail.com> escribió:

>
> Is there a better way to do validation other than json_decode?
>


Better way than json_decode... Always from the core perspective

>

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

Just Want to remind that this discussion is not about "a json parser can be
written in PHP or not?".

We Have a JSON parser already in the core, ready to be use for validation.

Does it make sense to have another parser in User land to do validation if
We already have one?

Is there a better way to do validation other than json_decode?



El vie., 26 de agosto de 2022 12:48, Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> escribió:

> Hi Tim,
>
> pt., 26 sie 2022 o 12:15 Tim Düsterhus  napisał(a):
>
>> Hi
>>
>> On 8/26/22 11:14, Hans Henrik Bergan wrote:
>> >> you can't efficiently validate JSON in userland
>> >
>> > Has anyone actually put that claim to the test? Has anyone actually
>> made a
>> > userland json validator (not just wrap json_decode()/json_last_error())
>> for
>> > performance comparison?
>> > ( if not, https://www.json.org/JSON_checker/JSON_checker.c  would
>> probably
>> > be a good start)
>> >
>>
>> Worded like "you can't efficiently" the claim is false. Of course you
>> can memory-efficiently validate the input by traversing the string byte
>> by byte and keeping track of the nesting.
>>
>> However the points that make a userland implementation infeasible are:
>>
>> 1. Writing a JSON parser is non-trivial as evidenced by:
>> https://github.com/nst/JSONTestSuite. I expect userland implementations
>> to be subtly buggy in edge cases. The JSON parser in PHP 7.0+ is
>> certainly more battle-tested and in fact it appears to pass all of the
>> tests in the linked test suite.
>>
>> 2. Even if the userland implementation is written very carefully, it
>> might behave differently than the native implementation used by
>> json_decode() (e.g. because the latter is buggy for some reason or
>> because the correct behavior is undefined). This would imply that an
>> input string that was successfully validated by your userland parser
>> might ultimately fail to parse when passed to json_decode(). This is
>> exactly what you don't want to happen.
>>
>
> Now this is an argument I could think of.
> But that one is not even mentioned in RFC.
>
> The JSON_checker.c example delivered by json.org is probably not
> something impossible
> as it required around 1h of work to port it see working implementation
> here https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc
>
> Cheers,
> Michał Marcin Brzuchalski
>

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Michał Marcin Brzuchalski]

Hi Tim,

pt., 26 sie 2022 o 12:15 Tim Düsterhus  napisał(a):

> Hi
>
> On 8/26/22 11:14, Hans Henrik Bergan wrote:
> >> you can't efficiently validate JSON in userland
> >
> > Has anyone actually put that claim to the test? Has anyone actually made
> a
> > userland json validator (not just wrap json_decode()/json_last_error())
> for
> > performance comparison?
> > ( if not, https://www.json.org/JSON_checker/JSON_checker.c  would
> probably
> > be a good start)
> >
>
> Worded like "you can't efficiently" the claim is false. Of course you
> can memory-efficiently validate the input by traversing the string byte
> by byte and keeping track of the nesting.
>
> However the points that make a userland implementation infeasible are:
>
> 1. Writing a JSON parser is non-trivial as evidenced by:
> https://github.com/nst/JSONTestSuite. I expect userland implementations
> to be subtly buggy in edge cases. The JSON parser in PHP 7.0+ is
> certainly more battle-tested and in fact it appears to pass all of the
> tests in the linked test suite.
>
> 2. Even if the userland implementation is written very carefully, it
> might behave differently than the native implementation used by
> json_decode() (e.g. because the latter is buggy for some reason or
> because the correct behavior is undefined). This would imply that an
> input string that was successfully validated by your userland parser
> might ultimately fail to parse when passed to json_decode(). This is
> exactly what you don't want to happen.
>

Now this is an argument I could think of.
But that one is not even mentioned in RFC.

The JSON_checker.c example delivered by json.org is probably not something
impossible
as it required around 1h of work to port it see working implementation
here https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Tim Düsterhus]

Hi

On 8/26/22 11:00, Michał Marcin Brzuchalski wrote:

A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles 1% of
use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the next
PhpToken::validate.
All above can be valid if we trust that people normally validate 300MB
payloads to do nothing if they DON'T fail and there is nothing strange
about that.


You phrase this as if this was a bad thing.

But yes, if PHP would include a YAML parser in core (there appears to be 
one in PECL) then having a yaml_validate() function with a value-add 
compared to actually constructing the object representation then it 
would certainly be an appropriate inclusion. I don't see why JSON should 
be special here.


For XML my understanding is that the XMLReader class can already be used 
to efficiently validate an XML input in userland [1], because that class 
is defined to be a streaming parser. These types of parsers are not 
uncommon in XML land.


Best regards
Tim Düsterhus

[1] https://www.php.net/manual/en/xmlreader.isvalid.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Tim Düsterhus]

Hi

On 8/26/22 11:14, Hans Henrik Bergan wrote:

you can't efficiently validate JSON in userland


Has anyone actually put that claim to the test? Has anyone actually made a
userland json validator (not just wrap json_decode()/json_last_error()) for
performance comparison?
( if not, https://www.json.org/JSON_checker/JSON_checker.c  would probably
be a good start)



Worded like "you can't efficiently" the claim is false. Of course you 
can memory-efficiently validate the input by traversing the string byte 
by byte and keeping track of the nesting.


However the points that make a userland implementation infeasible are:

1. Writing a JSON parser is non-trivial as evidenced by: 
https://github.com/nst/JSONTestSuite. I expect userland implementations 
to be subtly buggy in edge cases. The JSON parser in PHP 7.0+ is 
certainly more battle-tested and in fact it appears to pass all of the 
tests in the linked test suite.


2. Even if the userland implementation is written very carefully, it 
might behave differently than the native implementation used by 
json_decode() (e.g. because the latter is buggy for some reason or 
because the correct behavior is undefined). This would imply that an 
input string that was successfully validated by your userland parser 
might ultimately fail to parse when passed to json_decode(). This is 
exactly what you don't want to happen.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Tim Düsterhus]

Hi

On 8/26/22 10:56, Paul Crovella wrote:

I'm for this as well. Though something more than a boolean is useful to
indicate when the max depth has been exceeded as that's not strictly a
problem with the json's validity.



Yes, it's not strictly invalid JSON, but I expect json_validate() to be 
used as a check to mean "will json_decode() be able to decode the JSON 
with these parameters". Then `false` is the logical result when 
exceeding the depth.


Also json_last_error() will do what you expect it to do: 
https://github.com/php/php-src/pull/9399/files#diff-1cdb6c7eb68aa60b323b056a06d6f7427b38e9d8d967ce97992129ff65c7951eR55. 
So you can find out the reason why the JSON is invalid.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 11:55, Peter Bowyer
() escribió:
>
> That's a good point which I had overlooked. Does an exception make most
> sense when this happens?
>
> Peter

I just got a code review from Derick Rethans explaining me that a
validation routine should not throw an exception.

I think is a good idea to take it out, after all , the depth parameter
is part of the validation too.

RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Peter Bowyer]

On Fri, 26 Aug 2022 at 09:56, Paul Crovella  wrote:

> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.
>

That's a good point which I had overlooked. Does an exception make most
sense when this happens?

Peter

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 11:43, Andreas Leathley
() escribió:
>
> On 26.08.22 11:00, Michał Marcin Brzuchalski wrote:
>
> There is already a way to validate XML in PHP, and Yaml or PHP is
> something within the control of a PHP programmer, while JSON is mostly
> used as a format for communication in APIs, so you never know what you
> get. If with a new function it becomes much easier to defend against a
> Denial-of-Service attack for some parts of a JSON API, then this can be
> a good addition just for security reasons.
>
> But this reason, which most resonates with me, is currently missing in
> the RFC, so I would suggest to add that fast / efficient validation of a
> common communication format reduces the attack surface for
> Denial-of-Service attacks.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

For sure I will add this. Thanks a lot !! That is exactly why we
are having this discussion. Once again, Thanks!

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 11:35, Michał Marcin Brzuchalski
() escribió:
> Your examples are a couple of functions.
> Assuming that they're heavily used is as true as my assumptions.
>
> Cheers,

Is good you clarify that your numbers were assumptions.

By the way, I never said anything about how my examples were use in
real life, I just provided them as examples of a "need"/requirement to
do something.

Thanks for participating.

Cheers.

RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Andreas Leathley]

On 26.08.22 11:00, Michał Marcin Brzuchalski wrote:

A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles 1% of
use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the next
PhpToken::validate.
All above can be valid if we trust that people normally validate 300MB
payloads to do nothing if they DON'T fail and there is nothing strange
about that.


There is already a way to validate XML in PHP, and Yaml or PHP is
something within the control of a PHP programmer, while JSON is mostly
used as a format for communication in APIs, so you never know what you
get. If with a new function it becomes much easier to defend against a
Denial-of-Service attack for some parts of a JSON API, then this can be
a good addition just for security reasons.

But this reason, which most resonates with me, is currently missing in
the RFC, so I would suggest to add that fast / efficient validation of a
common communication format reduces the attack surface for
Denial-of-Service attacks.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Michał Marcin Brzuchalski]

Hi Juan,

pt., 26 sie 2022 o 11:26 juan carlos morales 
napisał(a):

> El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
> () escribió:
> >
> > A `json_decode()` is a substitute that IMO solves 99% of use cases.
> > If I'd follow your logic and accept every small addition that handles 1%
> of use cases, somebody will raise another RFC
> > for simplexml_validate_string or yaml_validate and the next
> PhpToken::validate.
> > All above can be valid if we trust that people normally validate 300MB
> payloads to do nothing if they DON'T fail and there is nothing strange
> about that.
> >
> > Cheers,
> >
>
> How can you make such an assertion in those numbers (99% of use cases
> and son on, that you mention) ? Can you give us more information about
> this assertions?
>
> I have provide real examples where the need to validate-only a
> json-string is actually needed, also the need from our developers
> community asking for this.
>

Your examples are a couple of functions.
Assuming that they're heavily used is as true as my assumptions.

Cheers,

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 11:26, juan carlos morales
() escribió:
>
> How can you make such an assertion in those numbers (99% of use cases
> and son on, that you mention) ? Can you give us more information about
> this assertions?
>
> I have provide real examples where the need to validate-only a
> json-string is actually needed, also the need from our developers
> community asking for this.
>
> RFC: https://wiki.php.net/rfc/json_validate
>
> Implementation: https://github.com/php/php-src/pull/9399

By the way you dont need to frame this function to handle 300MB of
json-string, as I already mentioned a couple of times, that a 2 MB
json-sring validation with json_decode() needs a large amount of
memory to be validated, possibly hitting the allowed memory limit,
which usually is not that high at all.

RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
() escribió:
>
> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of 
> use cases, somebody will raise another RFC
> for simplexml_validate_string or yaml_validate and the next 
> PhpToken::validate.
> All above can be valid if we trust that people normally validate 300MB 
> payloads to do nothing if they DON'T fail and there is nothing strange about 
> that.
>
> Cheers,
>

How can you make such an assertion in those numbers (99% of use cases
and son on, that you mention) ? Can you give us more information about
this assertions?

I have provide real examples where the need to validate-only a
json-string is actually needed, also the need from our developers
community asking for this.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 10:56, Paul Crovella
() escribió:
>
> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.

Thanks, seems to be good idea to take it out, and I will. Nice observation.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 10:28, Peter Bowyer
() escribió:
>
> Hi Juan,
>
> On Thu, 25 Aug 2022 at 17:02, juan carlos morales 
>  wrote:
>>
>> RFC: https://wiki.php.net/rfc/json_validate
>
>
> Thanks for bringing forward this RFC. I am in favour of this change, as you 
> can't efficiently validate JSON in userland.
>
> Like Rowan I'm not convinced JSON_THROW_ON_ERROR belongs here. I can't think 
> of a case where more than a boolean response is needed.
>
> Peter

Seems that will be a good idea to take out the usage of the flag
JSON_THROW_ON_ERROR after all. That was a nice and objective critic
and I appreciate it. Thanks! I will take it out of the implementation.

Regards

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Hans Henrik Bergan]

quote
> you can't efficiently validate JSON in userland

Has anyone actually put that claim to the test? Has anyone actually made a
userland json validator (not just wrap json_decode()/json_last_error()) for
performance comparison?
( if not, https://www.json.org/JSON_checker/JSON_checker.c  would probably
be a good start)

On Fri, 26 Aug 2022 at 11:00, Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Dusk,
>
> pt., 26 sie 2022 o 08:17 Dusk  napisał(a):
>
> > On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski <
> > michal.brzuchal...@gmail.com> wrote:
> > > The same goes here and I'm not convinced we should introduce next small
> > function that can be simply implemented in user land.
> >
> > What "simple implementation in userland" do you have in mind? Can you
> > provide an example?
> >
> > json_decode() is not an acceptable substitute here -- as David Gebler has
> > observed, decoding a large JSON structure can have a significant impact
> on
> > memory usage, even if the data is immediately discarded. Any
> implementation
> > based on string processing, on the other hand, is likely to be
> dramatically
> > slower, and may have subtle differences in behavior from PHP's JSON
> parser.
>
>
> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of
> use cases, somebody will raise another RFC
> for simplexml_validate_string or yaml_validate and the next
> PhpToken::validate.
> All above can be valid if we trust that people normally validate 300MB
> payloads to do nothing if they DON'T fail and there is nothing strange
> about that.
>
> Cheers,
>

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Michał Marcin Brzuchalski]

Hi Dusk,

pt., 26 sie 2022 o 08:17 Dusk  napisał(a):

> On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> > The same goes here and I'm not convinced we should introduce next small
> function that can be simply implemented in user land.
>
> What "simple implementation in userland" do you have in mind? Can you
> provide an example?
>
> json_decode() is not an acceptable substitute here -- as David Gebler has
> observed, decoding a large JSON structure can have a significant impact on
> memory usage, even if the data is immediately discarded. Any implementation
> based on string processing, on the other hand, is likely to be dramatically
> slower, and may have subtle differences in behavior from PHP's JSON parser.


A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles 1% of
use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the next
PhpToken::validate.
All above can be valid if we trust that people normally validate 300MB
payloads to do nothing if they DON'T fail and there is nothing strange
about that.

Cheers,

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Paul Crovella]

On 8/26/2022 1:28 AM, Peter Bowyer wrote:

Hi Juan,

On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.mora...@gmail.com> wrote:


RFC: https://wiki.php.net/rfc/json_validate



Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON in userland.

Like Rowan I'm not convinced JSON_THROW_ON_ERROR belongs here. I can't
think of a case where more than a boolean response is needed.

Peter




I'm for this as well. Though something more than a boolean is useful to 
indicate when the max depth has been exceeded as that's not strictly a 
problem with the json's validity.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Peter Bowyer]

Hi Juan,

On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.mora...@gmail.com> wrote:

> RFC: https://wiki.php.net/rfc/json_validate


Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON in userland.

Like Rowan I'm not convinced JSON_THROW_ON_ERROR belongs here. I can't
think of a case where more than a boolean response is needed.

Peter

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[juan carlos morales]

El vie, 26 ago 2022 a las 6:47, Michał Marcin Brzuchalski
() escribió:
>
>
> I share the same opinion you expressed here even though you admit in recent 
> email that you changed your mind.
>
> In recent versions we tend to accept more and more small standard library 
> functions with IMO questionable argumentation. The same goes here and I'm not 
> convinced we should introduce next small function that can be simply 
> implemented in user land.

Sorry but I dont think that a JSON parser with memory usage zero (or
maybe a few bytes) can be simply done in the userland. This function
(json_validate) is small by itself, but gives you access to the JSON
parser. Can you please provide an example of what you commented?

> Any example testing > 3MB JSON string are for me edge cases that normally 
> don't happen often to deserve special treatment.

I don't agree with your definition of "edge case" here, as edge cases
depend/belong on/to the system under analysis.

By the way, the test case provided in the PR , "test 005" uses a
json-string of about 3 MB (maybe 3.1) , and in order to decode it
json_decode() needs something around 109 MB of memory. For me,
validation can be done in a better and efficient way, like it has been
probe with this proposal.

> If we keep the tendency to pollute already bloated standard library with an 
> army of small functions that could have not exists and be replaced with 
> normal PHP counterparts IMHO we'll end with frustration from developers as I 
> believe DX slowly falls down here.

Last but not least, I want to say that the function json_validate() is
small, easy to maintain and extend if needed, and at the same gives us
access to something that is not trivial to write in userland  the
existing JSON parser.


RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Dusk]

On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski 
 wrote:
> The same goes here and I'm not convinced we should introduce next small 
> function that can be simply implemented in user land.

What "simple implementation in userland" do you have in mind? Can you provide 
an example?

json_decode() is not an acceptable substitute here -- as David Gebler has 
observed, decoding a large JSON structure can have a significant impact on 
memory usage, even if the data is immediately discarded. Any implementation 
based on string processing, on the other hand, is likely to be dramatically 
slower, and may have subtle differences in behavior from PHP's JSON parser.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php