bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: bug#15260: cannot build in a directory with non-ascii characters
Date: Thu, 31 Oct 2013 14:09:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>>>>> "Eli" == Eli Zaretskii <address@hidden> writes:

>> From: Stefan Monnier <address@hidden>
>> Cc: Kenichi Handa <address@hidden>,  address@hidden
>> Date: Wed, 30 Oct 2013 21:01:21 -0400
>> 
>> > Why do we have this confusing inconsistency?
>> 
>> make_string is a bug.  There's no way to know/guess if the string should
>> be unibyte or multibyte.  So, it should be removed and replaced by calls
>> to either make_unibyte_string or make_multibyte_string.

> Here's one more gotcha I bumped into while working on this bug.

> Suppose the filesystem where you build Emacs uses a file-name encoding
> whose coding-system-category is 'charset'.  Example: cpNNNN.  Then,
> when Emacs comes up after dumping, it loads subdirs.el in each
> directory on load-path.  To do this, it calls 'openp' to look for
> DIR/subdirs.el, which involves calling ENCODE_FILE on
> "DIR/subdirs.el", in order to pass that to 'faccessat' or 'open'.
> Now, if the charset that is needed to encode this file name is not yet
> loaded into Emacs, Emacs will try to load it.  To this end, it will
> look along charset-map-path for the corresponding map file, and for
> that it will again call 'openp', recursively.  That 'openp' call will
> again want to ENCODE_FILE with the same encoding, which will again
> cause Emacs to try to load the corresponding map file, etc. etc.,
> until we exhaust the specpdl stack.

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.
How do we get into such a state?


        Stefan





reply via email to

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