Re: comments on string-test.scm
Per Bothner 14 May 2017 19:00 UTC
On 05/14/2017 08:45 AM, Jim Rees wrote:
> Thanks for give me an excuse to fix up some of my own bugs.
>
> The 15-or-so tests starting with (test-equal #f (string=? "Fuss" fuss")) need to be wrapped with cond-expand to be disabled without full-unicode-strings support.
I'm rather unclear what the difference is between full-unicode and
full-unicode-strings, and which to use. R7RS only has full-unicode,
so my inclination is to just use that.
> This line seems to have some non-portable type declaration syntax:
>
> "-(define (translate-space-to-newline str::string)::string"
>
> There are a few instances of #\Space and #\Newline which are portably valid only if #!fold-case is in effect.
>
> " (test-equal 6 (length str))"
>
> Should be (test-equal 6 (string-length str))
Fixed in the Kawa repository.
> The string->utf16 tests assume that the declared feature big-endian or little-endian is consistent with the specification when it refers to an "implementation-dependent endianness". While that relationship may seem obvious, perhaps it should be made explicit in the specification.
I changed the text for string->utf16 in my working copy to:
The bytevectors returned by string->utf16 begin with a BOM that declares an
implementation-dependent endianness. The latter *should* match the big-endian
or little-endian identifier returned by 'features'. The bytevector elements following
that BOM encode the given substring using that endianness.
--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/