[gambit-list] Low prio feature request: GC:able symbols, perhaps via a separate configure option --enable-gc:able-symbols

Mikael mikael.rcv at gmail.com
Tue Oct 22 12:11:45 EDT 2013


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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20131022/cb1cde08/attachment.html 


More information about the Gambit-list mailing list