GNU bug report logs -
#15260
cannot build in a directory with non-ascii characters
Previous Next
Reported by: Glenn Morris <rgm <at> gnu.org>
Date: Tue, 3 Sep 2013 17:47:02 UTC
Severity: wishlist
Found in version 24.3
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>>>>> "Eli" == Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Kenichi Handa <handa <at> gnu.org>, 15260 <at> debbugs.gnu.org
>> 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
This bug report was last modified 11 years and 201 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.