On Fri, Sep 30, 2022 at 3:28 AM Marc Nieper-Wißkirchen <
[email protected]> wrote:
> I don't think that this is a good idea. Instead, I think it is much
> more dangerous than the issue below about symbol GC because the latter
> can be fixed by implementers. A SRFI 233 implementation may try to
> extract as much information as possible, but it is unclear whether the
> information the implementation thinks is there is the same information
> the creator of the INI file intended to put into it if they don't
> speak the same language.
There is never any guarantee of a creator's intent; we are all condemned to
interpret the input we receive as best we can. But that is a point about
communication in general that cannot be resolved by this SRFI.
> In other words, whatever is returned by the
> SRFI 233 generator comes either from a correctly formatted INI file
> (in the sense of SRFI 233)
>
Well, in that case there is no issue, since *every* text file is correctly
formatted in the sense of SRFI 233. Once any comments and leading/trailing
whitespace has been removed, each line is classified as:
* blank
* section header (begins with #\[ and ends with #\])
* key-value pair (contains at least one key-value separator)
* key with null value (any other line)
If you apply SRFI 233 to a file of Scheme code or a copy of the U.S.
Declaration of Independence from Project Gutenberg, you get what you
deserve semantically, but syntactically both of these files are perfectly
okay.
> Then these Schemes should be fixed ASAP or not be used in critical
> areas. Or they should not implement SRFI 233. Instead of having the
> design of an API guided by obvious deficiencies of some Schemes in
> existence, it should be seen as a motivation for the authors of these
> Schemes to fix their GC. It will also help Scheme's reputation if
> implementations become better and more robust.
>
In that case, I would have to add the following paragraph to the SRFI:
SECURITY WARNING: This SRFI should NOT be used unless the Scheme
implementation is capable of garbage collecting symbols, as reading
maliciously crafted files can fill up memory with otherwise-useless
symbols. It is also possible to use the SRFI. At the time of writing,
this is the list of Schemes that the author knows to provide garbage
collection of symbols: (Chicken Racket).
And before I wrote anything of the sort, I would withdraw the whole SRFI.
A user of the SRFI 233 wants to process the returned keys somehow. The
> simplest form would be a case construct. This does not work with
> strings so the user would probably use `string->symbol` by themselves.
>
Or write a more forgiving `string-case` macro, or more to the point, use a
variant of `case` which accepts a predicate argument.
> Or the key-value pairs have to be stored somehow. Again, a
> symbol-based hash table is more efficient than a string-based
> hashtable. In any case, I think that symbols are by far a better
> abstraction than strings.
>
In the abstract, you are right, but this SRFI is about the concrete. ("I
love little boys in the abstract, but not in the concrete." This is a pun.)
> No, but the same thread (or even other threads) can interleave
> writing/reading from the port. This can even make sense to skip
> certain lines (known to be ill-formed) during reading or to write
> extra information during writing.
>
I see no point in jumping through hoops to make sure such oddball use cases
are supported.
