[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New escape method proposal (was: Re: Possible solution for special c
From: |
Eli Zaretskii |
Subject: |
Re: New escape method proposal (was: Re: Possible solution for special characters in makefile paths) |
Date: |
Wed, 23 Apr 2014 20:51:59 +0300 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Wed, 23 Apr 2014 13:43:21 -0400
>
> > What about non-ASCII characters? Make works in the current locale
> > (AFAIK), so non-ASCII characters can have arbitrary single- or
> > multi-byte encodings. Will the above encoding of special characters
> > be compatible with the locale-encoded non-ASCII characters?
>
> As long as whatever encoding is used provides the same meaning for
> character codes 0-127 (that's what I was trying to say above). So a
> multi-byte encoding is fine, as long as it doesn't re-use the values
> 0-127 in the encoding to mean something else in the second or subsequent
> bytes.
So ISO-2022 and its derivatives are out?
> Actually the restriction is already there in make since make doesn't do
> anything at all special for multibyte today, and does a lot of string
> parsing based on standard ASCII characters. For example make already
> matches against "}" which is ASCII 125; if that appeared as the second
> byte in a multi-byte encoding it would break make today.
I don't know about }, but \ definitely can happen in a DBCS Windows
locale.
But what triggered my question was that we seem to be introducing new
"reserved" characters, the ones to be used to encode the special ones.