Re: New escape method proposal (was: Re: Possible solution for special characters in makefile paths)

> From: Paul Smith <[email protected]>
> Cc: [email protected]
> 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.