[Openmcl-devel] [babel-devel] Changes
james.anderson at setf.de
Sun Apr 12 18:38:15 EDT 2009
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
> 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
would one need to signal an error upon assignment to a slot of type
> 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?
More information about the Openmcl-devel