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.