Email list hosting service & mailing list manager

too low-level Alex Shinn (25 May 2020 00:46 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:09 UTC)
Re: too low-level Amirouche Boubekki (03 Jun 2020 06:00 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:28 UTC)
Re: too low-level John Cowan (04 Jun 2020 19:53 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 20:54 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 22:50 UTC)
Re: too low-level Arthur A. Gleckler (04 Jun 2020 23:31 UTC)
Re: too low-level John Cowan (05 Jun 2020 00:16 UTC)
Re: too low-level Alex Shinn (05 Jun 2020 04:06 UTC)
Re: too low-level John Cowan (05 Jun 2020 17:45 UTC)

Re: too low-level Marc Nieper-Wißkirchen 04 Jun 2020 10:28 UTC

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

> The compiler could provide introspection, though,
> into the size of the current stack, or you could just
> binary search and see how deep it can go, but in
> practice I doubt anyone would do this.

It's probably enough to encourage implementations to stop parsing a
json string and signaling an error in case some implementation-defined
internal limit (whatever this is) is reached to prevent the
overallocation of resources.