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

[Paul Smith]

On Wed, 2014-04-23 at 20:51 +0300, Eli Zaretskii wrote:
> > 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?

I'm no expert but it definitely does not look like the full ISO 2022
will work with make currently, and so it wouldn't work after this change
either.

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

Yes, at least one new reserved character and possibly more, depending on
the method of encoding.  It is possible, if we're careful about it, that
we could avoid any reserved characters by encoding the encoding
character as well (we'd have to solve the idempotency problem as Frank
and I discussed back in Feb).


However, I'm not aware of any encoding which currently works with make,
that would stop working anymore after this restriction is added.  If you
are aware of encodings which match ASCII for all single-byte characters
special to make today but which don't match for the rest of the
characters <128, I'd be interested to hear details.