guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.


From: Mark H Weaver
Subject: Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.
Date: Sun, 01 May 2011 17:48:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Andy Wingo <address@hidden> writes:
> On Fri 29 Apr 2011 19:30, Noah Lavine <address@hidden> writes:
>> Also, are there any characters that are valid in filenames on some
>> systems but invalid on other systems?
>
> Ah, I see you are under the delusion that paths are composed of
> characters :)  This is not the case.  To the OS, paths are
> NUL-terminated byte arrays, with some constraints about their
> composition, but which are not necessarily representable as strings.

This is the case on POSIX, but we should keep in mind that on some
systems (e.g. Windows NT) filenames are considered character data,
or at least so says PEP 383 <http://www.python.org/dev/peps/pep-0383/>

IMHO, it would be best to avoid embedding into Guile the assumption that
filenames, environment variables, command-line arguments, etc, are
really bytevectors.

> Basically I think the plan should be to add scm_from_locale_path,
> scm_from_raw_path, etc to filesys.[ch], and change any
> pathname-accepting procedure in Guile to accept path objects, producing
> them from strings when given strings, and pass the bytevector
> representation to the raw o/s procedures like `open' et al.

I like this idea, but we should keep in mind that we face the same
problem with things like environment variables, command-line arguments,
etc.  Ideally, we should try to come up with a coherent story and set of
APIs for dealing with all of these data that are string-like, but
actually bytevectors on some systems.

     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]