make-alpha
[Top][All Lists]
Advanced

[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.



reply via email to

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