too low-level Alex Shinn (25 May 2020 00:47 UTC)
Re: too low-level Amirouche Boubekki (28 May 2020 07:05 UTC)
Re: too low-level Alex Shinn (28 May 2020 08:27 UTC)
Re: too low-level Alex Shinn (28 May 2020 09:10 UTC)
Re: too low-level Amirouche Boubekki (03 Jun 2020 06:01 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 08:17 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 08:53 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 10:12 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 10:28 UTC)
Re: too low-level John Cowan (04 Jun 2020 15:59 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 16:29 UTC)
Re: too low-level John Cowan (04 Jun 2020 19:54 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 20:55 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 22:50 UTC)
Re: too low-level Arthur A. Gleckler (04 Jun 2020 23:32 UTC)
Re: too low-level John Cowan (05 Jun 2020 00:17 UTC)
Re: too low-level Alex Shinn (05 Jun 2020 04:07 UTC)
Re: too low-level John Cowan (05 Jun 2020 17:46 UTC)

Re: too low-level Marc Nieper-Wißkirchen 04 Jun 2020 08:53 UTC

Am Do., 4. Juni 2020 um 10:17 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:

> 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,

There are also implementations (usually those that try to implement
call/cc as efficient as possible) where there is really no stack but
everything is on the heap (with the nice impact that there is no
superficial stack limit).

> 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.

How can a certain kind of depth be guaranteed? Even when the stack
limit is known, the size of the stack frames may vary and depend on
the data being parsed.