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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
