Re: Non-ASCII characters in @include search path

[Patrice Dumas]

On Sat, Feb 26, 2022 at 08:39:40PM +0000, Gavin Smith wrote:
> On Sat, Feb 26, 2022 at 06:57:34PM +0000, Gavin Smith wrote:
> > > I do not think so.  I think that it needs to be encoded if mixed with
> > > non ascii strings.  (Also, it could be set to something non ascii, as
> > > customization but this should be pretty rare).
> > 
> > Yes, you're right: if the EXTENSION string has the UTF-8 flag on and
> > it is concatenated with a string with the UTF-8 flag off but which is
> > encoded in UTF-8, then the same "double UTF-8" problem will occur.
> 
> On further thought and testing, I think it may be okay after all.  The UTF-8
> flag is not set on a string set from an ASCII-only string constant.

Ok.  Though beware that any of the customization variables associated
strings may be decoded if they come from the commend line, or even if
set from init files.  We need to encode those that we want to be sure
are encoded and not character strings.

For instance, for now passing -s 'SUBDIR something' could break again
some tests, it needs to be encoded.  We can have a list to encode (if
coming from init files) or not decode (if from command line).

-- 
Pat