On 14/12/2004 17:47, John Cowan wrote:
Peter Kirk scripsit:
I think the problem here is that a Unix filename is a string of octets, not of characters. And so it should not be converted into another encoding form as if it is characters; it should be processed at a quite different level of interpretation.
Unfortunately, that is simply a counsel of perfection.
Unix filenames are in general input as character strings, output as character
strings, and intended to be perceived as character strings. The corner
cases in which this does not work are not sufficient to overthrow the
power and generality to be achieved by assuming it 99% of the time.
This is a design flaw in Unix, or in how it is explained to users. Well, Lars wrote "Basically, you are not supposed to use strcpy to process filenames." I'm not sure if that is his opinion or someone else's, but the only safe way out of this mess is never to process filenames as strings.
This may be called a "trick" but it looks like it could very easily be a security hole. For example, a filename 0x41 0x08 0x42 will be displayed the same as just 0x42, in a Latin-1 or UTF-8 locale. Your friend's trick has become an open door for spoofers.(A private correspondent has come up with an ingenious trick which depends on being able to create files named 0x08 and 0x7F, but it truly is a trick, and in any case depends only on an ASCII interpretation.)
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
