Am Mo., 23. Sept. 2024 um 11:37 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
> On 22 Sep 2024, at 14:56, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> > wrote: > > > (Apart from this, some implementations GC symbols, others do not, so > even if SRFI 254 allowed symbols as weak keys, you wouldn't see the same > behaviour everywhere.) > > Implementations which don’t GC symbols are broken and vulnerable to DDoS > attacks by memory exhaustion the moment you expose an SXML or JSON parser > to the internet using one. See e.g. my issue on Gambit: < > https://github.com/gambit/gambit/issues/675> > While I think that implementations should aim for GCing symbols, interning arbitrary JSON strings as symbols is at least questionable anyway. > R7RS Large will probably make weaknesses in collection like this > implementation-specified, so conforming impls will have to document if they > can’t collect symbols. > Has this been discussed already? > >> This needs a stronger definition of what has ‘location’ and what not > than R7RS small provides. Also stronger than R6RS’s, to my knowledge. > > > > What does not have a location is not important for SRFI 254. > > If you are going to ban keys that don’t have locations, it’s very > important. > Firstly, it doesn't make sense to use keys without locations, as I tried to explain. Secondly, SRFI 254 does not ban them but leaves it open. It is like saying strings are not important for, say, "+". R7RS leaves it open what happens when you evaluate (+ 1 "zwei"). > What is important is that there are enough types that have a location, > and this is in RnRS (see the listed types above). > > But RnRS’s definition of this is not strong enough and you should make it > stronger instead of depending on it. > I still fail to understand in what sense it is not strong enough. It lists types that are guaranteed to denote locations or sequences of locations. What else would be needed?
