On Wed, Jun 3, 2020 at 3:01 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
Le jeu. 28 mai 2020 à 10:27, Alex Shinn <xxxxxx@gmail.com> a écrit :
> Yes, there will be implementation limits.  I suggest to mention in the
> SRFI that JSON parsing is subject to an implementation-defined
> depth limit, which should be no smaller than X (e.g. 100).
> Otherwise, the default value of infinity is of no use, and any other
> value will be difficult to determine and non-portable.

Like I tried to explain previously, the limit is applied to reading
and must be set on a per-application basis.

Yes, I understood perfectly.  You are concerned with some specific
JSON schema where you know, a priori, the depth will never exceed
some value d (although this is fragile).  You would then set the parameter
to d in an application using that JSON schema.

The problem, however, is that this parameter is effectively read-only,
in the sense that the true limit is implementation and platform defined.
If the implementation has a stack depth limit of 100 recursions, trying
to set the parameter to 120 is of no use.  On the other hand, trying to
set the parameter to 80 is not needed.  It's theoretically possible for
an impl to _not_ use recursion and use a heap-based data structure,
but in this case the limit is only heap memory.  If you want to limit
heap memory, the depth doesn't help.  You need some limit on total
object size, otherwise they can just send a 10G string.

So you could change this to a read-only parameter (actually it would
need to be a procedure since the standard doesn't provide support
for immutable parameters), probably with the semantics that it
guarantees at least that much depth (the value can be difficult to
determine statically).  Then an application could check against it,
and bail out with an error "implementation doesn't support required
depth" before even parsing.