[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15260: cannot build in a directory with non-ascii characters

From: Eli Zaretskii
Subject: bug#15260: cannot build in a directory with non-ascii characters
Date: Thu, 31 Oct 2013 21:41:04 +0200

> Date: Thu, 31 Oct 2013 20:37:52 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> > From: Stefan Monnier <address@hidden>
> > Cc: address@hidden,  address@hidden
> > Date: Thu, 31 Oct 2013 14:09:39 -0400
> > 
> > So you mean that we have:
> > - charset-map-path is a multibyte string.
> > - the file-name encoding uses a charset that's not yet loaded.
> Yes.
> > How do we get into such a state?
> Not sure about the details, since I don't really understand when Emacs
> needs to load the charset map.  Perhaps the map is needed only when we
> need to encode a string, not for decoding?

Actually, as can be seen from load_charset_map, we do different things
when the map is needed for decoding and for encoding.  So what
probably happened was that when the file names in load-path etc. were
decoded from cpNNNN, the map file was loaded and load_charset_map did
whatever was necessary to set up the decoder for this encoding.  Then,
when we need to encode a file name using the same cpNNNN, the map file
is loaded again, and load_charset_map now sets up the encoder.

When the decoder was set up, charset-map-path was still in unibyte
form, so the whole thing worked, because ENCODE_FILE doesn't try to
encode unibyte strings.  But once charset-map-path itself was decoded,
the recursive call to 'openp' inside load_charset_map_from_file tried
to encode it, and triggered infinite recursion.

reply via email to

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