Re: [Scheme-reports] poll: invalid item #315 from 5th ballot

[Takashi Kato <ktakashi@x>]

Hi there,

I have read the discussion of item #315 and would like you to re-consider.

Firstly, #\null is not only for terminator but also separator. Such as ${username}.\0.${password}

Secondly, #\null can't be simply mapped #vu8(0) on UNICODE world. On UTF16 it will be
#vu8(0 0).

If the implementation ties closely to C, then it should use bytevector instead of using string directly.
It's because not all implementations using UTF8 for their internal string encoding. Even C library can

have non ASCII or UTF8 strings fot its internal encoding, IMHO.


As long as R7RS has bytevector, then string should be able to contain #\null otherwise user need to
know the length of #\null, then string->utf16 procedure cannot simply be provided. (if R7RS has it)

>From here is simply my opinion;
On PKCS#12 requires password with UTF16 null character for its cipher and I think it's better if I can
write like this;

  (string->utf16 (string-append password "\x0;") 'big)

instead of

  (bytevector-append (string->utf16 password 'big) #vu8(0 0))

In this case, I don't need to do much conversion but consider if there are multiple strings need to be
converted to UTF16 or even user can specify the encoding (such as UTF32 or so) separated by #\null
character, it would look like this if string can't contain #\null;

  (bytevector-append (string->utf16 s1 'big) #vu8(0 0) (string->utf16 s2 'big) #vu8(0 0) ...)


Isn't this ugly?


Ciao

Takashi

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports