Re: [Chicken-hackers] CHICKEN in production

[Michele La Monaca]

On Tue, Oct 14, 2014 at 1:37 PM, "Jörg F. Wittenberger"
<address@hidden> wrote:
> Am 14.10.2014 um 04:25 schrieb John Cowan:
>>
>> Florian Zumbiehl scripsit:
>>
>>> String containing slash to filename? Exception! String containing colon
>>> to hostname? Exception! String containing NUL to C string? Exception!
>>
>> These aren't all the same.  Filenames and hostnames are specific uses of
>> strings, but C strings are just as general purpose as anyone else's
>> strings,
>> even though they can't handle NUL.
>>
>
> IMHO they are all the same too.  At least from a practitioners point of few.
> I doubt all to many of those even knew that the Scheme standard would be
> vague on allowing NUL as part of a string or not. Let alone recalling this
> in practice.  And I don't know how many Scheme implementations did reject
> such strings.  I know however that there is so much code out there, which
> expects NUL as legitimate character in Scheme strings, that I'd recommend to
> not reject it by default for a long time to come.
>
> This time may be used to gather some experience from multiple parties.

In this regard, it might be interesting to look at how a "modern C"
language like Go defines and handles strings.

"It's important to state right up front that a string holds arbitrary
bytes. It is not required to hold Unicode text, UTF-8 text, or any
other predefined format."

....

"Go source code is UTF-8, so the source code for the string literal is
UTF-8 text. If that string literal contains no escape sequences, which
a raw string cannot, the constructed string will hold exactly the
source text between the quotes. Thus by definition and by construction
the raw string will always contain a valid UTF-8 representation of its
contents. Similarly, unless it contains UTF-8-breaking escapes like
those from the previous section, a regular string literal will also
always contain valid UTF-8."

source: http://blog.golang.org/strings

Regards,
Michele