On Wed, Sep 28, 2022 at 7:22 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
> - The specification refers to a literal `=` several times where the value > of the `key-value-sep` is meant. Analogous for `;`. > Partly fixed. I have left the explicit ; and = intact in the list of rules, since it is already noted that they can be overridden. > - What happens when the `key-value-sep` or the `comment-delim` are > whitespace, especially a newline? > It is an error. Fixed. > - Is whitespace the whitespace from the lexical syntax of R6RS and/or R7RS? > No, it means a sequence of spaces and/or tabs (certainly not line delimiters). > - What happens if one of the strings fed to the accumulator contains > whitespace or any other special characters? > Whitespace is not a problem and is in fact quite common. It is an error if any string contains a line delimiter; fixed. If any string contains a key-value separator or comment delimiter, it's on you. I have noted that if there are multiple key-value separators, all but the first are part of the value. - The generator really should raise a well-defined exception (that would > derived from &error in the case of R6RS) if the INI file format is not of > the specified format. Only this way, one can be sure that the provided > textual data is interpreted correctly. Silent extensions by > implementations must not be permitted (at least not without setting a > special flag). > There is no use in pretending that INI format is precisely specified like XML or JSON. This library attempts to extract as much information as possible from an INI file no matter how ill-formed it is. I have added a version of this sentence to the Rationale. - The keys and section names really should be represented by symbols, not > strings. Symbols are interned, can be compared quickly and have a fast > hash function. All this is quite advantageous in the case of INI files. > Generating symbols from untrusted input allows a DoS attack on Schemes with naive garbage collectors (i.e. most of them), allowing memory to fill up with unreclaimable symbols. In any case, typically a program reads a small number of INI files, often just one, with no duplicate section or key names, so the advantages of using symbols are effectively nullified. - The strings returned by the generator should probably be immutable ones, > in general. > Fixed. I have noted that it is an error to mutate any of the returned strings and lists. > - Should the accumulator be allowed to cache results so that the writing > may be deferred until it receives an eof object? Should the generator be > allowed to read ahead? > Since there are no guarantees that Scheme ports do or don't don't buffer already, I see no point in mentioning this. - By symmetry, the accumulator really should not close the port when > receiving an eof object. It should just be error to feed anything but an > eof object into the accumulator afterwards. (BTW, `write` also does not > close a port when it receives an eof object.) > Fair enough. I have modified the code not to close any ports and noted that it is the user's responsibility to do so. This allows the use of the various wrappers like `with-input-from-file`. I have pushed all these changes to johnwcowan/srfi-233, along with removing the stray file named "srfi-233.sld". >
