Am Fr., 30. Sept. 2022 um 16:46 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Fri, Sep 30, 2022 at 3:28 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> 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.

Okay, but then I don't understand the reference to "ill-formed" in the
last sentence of the rationale (in your private draft) anymore.

And if there is no ill-formed INI file, I even more tend to agree to
those who think that standardizing anything about them is not a good
idea.

>>
>> 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).

You can add Chez to the list.

> And before I wrote anything of the sort, I would withdraw the whole SRFI.

I would say if a user fears that such an attack could happen and would
be a problem, they should use a different Scheme implementation. As I
said, not using symbols in SRFI 233 is only a solution as long as the
programmer doesn't use string->symbol, etc.

>> 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.)

This can be seen as an argument for making this SRFI's implementation
a GitXXX library.

>> 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.

I don't understand why this should be an oddball use case. And why
"jumping through hoops"? tt would be enough to say something with the
effect that the generator and the accumulator are not lazy.

Marc