Email list hosting service & mailing list manager

comments on string-test.scm Jim Rees (14 May 2017 15:45 UTC)
Re: comments on string-test.scm Per Bothner (14 May 2017 19:00 UTC)

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/