Dear Marc,
Posted as issue 44, https://github.com/feeley/gambit/issues/44: "./configure --enable-symbol-gc option ; Currently symbols don't GC, meaning you face risk of heap overflow & crash on any use of (read), SXML or other |string->symbol|-relying code w input from outside".
Within my personal frame of reference, this is the 3:rd or 2:nd highest prio for Gambit, as the current issue is almost or absolutely impossible for a Scheme user to mitigate, depending on the user problem complexity involved.
Feel free to give pointers on how the Gambit community could implement this.
Thanks, Mikael
2013/9/25 Mikael mikael.rcv@gmail.com
Hi!
For a lower prio than SMP feature request I wish to suggest GC:able symbols.
This would be of use to enable processing of symbols from unsafe or otherwise unknown sources such as frequently is the case in SXML and many other more or less standardized formats.
Currently in such use the Gambit process tends to be susceptible to heap overflow possibility/attacks unless there's additional complexity in the form of separate marshalling code that limits symbol import to a pre-specified set only.
Very secondarily, an extreme variant of such "unsafe formats" would be some forms of untrusted or otherwise unknown code - for running any form of untrusted code in Gambit, symbols being GC:able would be a key enabler as they'd save the untrusted code handling mechanism of the need to implement symbols<->uninterned symbol conversion in a copying proxy on start and on any passing of values between trusted and untrusted code, and also save of any weird complexity such a proxy would impose on object reference equality, cyclical references support etc.
I completely understand that probably the default non-GC:ing quality of symbols is extremely well motivated for minimalism or technical reasons, however wanted to suggest this due to the huge practical use and unifying quality this feature would bring, then as a separate configurable option I guess.
If anyone has any thought on this topic feel free to share,
Best regards, Mikael