[Openmcl-devel] [babel-devel] Changes

[james anderson]

On 2009-04-12, at 23:46 , Luís Oliveira wrote:

> ...
>
> That would work. But it certainly seems much more convenient to use
> Lisp strings directly. I'll try to illustrate that with a concrete
> example.
>
> These days, unix pathnames seem to be often encoded in UTF-8 but IIUC
> they can really be any random sequence of bytes -- or at least that
> seems to be the case on Linux.
>
> Suppose I was implementing a directory browser in Lisp. If I could use
> UTF-8B to convert unix pathnames into Lisp strings, it'd be
> straightforward to use Lisp pathnames, pass them around, manipulate
> them with the standard string and pathname functions, and still be
> able to access the respective files through syscalls later on. In this
> scenario, my program wouldn't have trouble handling badly formed UTF-8
> or other binary junk.
>

what happens in this scenario, should your program

  - combine such a tainted "string" with a string which comprises  
valid characters only?

  - attempt to encode such an object as utf-8?

is it enough to simply, informally relax the type constraint on  
string elements to permit non-characters?
would it be enough to signal an error upon an attempt to encode one  
as utf-8?
would one need to signal an error upon assignment to a slot of type  
STRING?

> The same applies to environment variables, command line arguments,  
> and so on.
>
> Does any of that make sense?

yes, but is it the right thing to do?