GNU bug report logs - #38
No coding system used for environment variables

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38 in the body.
You can then email your comments to 38 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: No coding system used for environment variables
Date: Wed, 05 Mar 2008 00:24:13 +0000

-------- Original Message --------
Subject: 	No coding system used for environment variables
Date: 	Thu, 21 Feb 2008 22:40:40 +0100
From: 	Göran Uddeborg <goeran <at> uddeborg.se>
To: 	bug-gnu-emacs <at> gnu.org



It seems there is no coding system applied to values of environment
variables.

I'm running a system using UTF-8.  My locale is sv_SE.utf8.  And emacs
uses UTF-8 as default most of the time.  When I open a new file for
example.

I do have issues with strings coming from environment variables
though.  I first discovered this in the vm mail system, since it
misinterpreted the variable MAIL which has the value
/var/spool/mail/göran encoded in UTF-8.  (In case your mailer mangles
it, the last file name component is g &ouml; r a n.)  But it also
causes problems in various places, for example with functions relating
to the home directory.  $HOME is /home/göran (same last component as
before).

As an example, I start emacs in my home directory, and do a few
experiments in the scratch buffer (which has a "u" for coding system
in the mode line):

   default-directory
   "/home/göran/"

Looks good.  I see my &ouml;.

   (expand-file-name "")
   "/home/göran"

Ok too.

   (expand-file-name "~")
   "/home/g\303\266ran"

Here the octal codes for a UTF-8 encoded &ouml; is shown instead of
the &ouml; itself.  The source of ~ is the environment variable HOME.
But if I explicitly ask for that variable:

   (getenv "HOME")
   "/home/göran"

Here I see the &ouml;.

Let's have a bit more fun.  Here I try to expand a FILE with my own
name:

   (expand-file-name "göran")
   "/home/göran/göran"

Looks the way I expected it.  Now the same thing, explicitly saying to
put it in the home directory:

   (expand-file-name "~/göran")
   "/home/g\xc3\xb6ran/göran"

The &ouml; in the file name is ok.  The &ouml; in the directory name
is strange again, only this time it is shown in hex rather than octal.

I asked about this on gnu.emacs.help first,
(http://groups.google.se/group/gnu.emacs.help/browse_thread/thread/80258d0a17e37138/75411fce63db9b2c#75411fce63db9b2c)
I was unsure if it was a bug or my lack of understanding.  But two
other posters have suggested I report it as a bug.



In GNU Emacs 22.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.12.1)
of 2007-11-06 on xenbuilder2.fedora.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-pop' '--with-sound' '--with-gtk' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -DSYSTEM_PURESIZE_EXTRA=16777216 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic''

Important settings:
 value of $LC_ALL: nil
 value of $LC_COLLATE: nil
 value of $LC_CTYPE: nil
 value of $LC_MESSAGES: nil
 value of $LC_MONETARY: nil
 value of $LC_NUMERIC: nil
 value of $LC_TIME: nil
 value of $LANG: sv_SE.utf8
 locale-coding-system: utf-8
 default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
 which-function-mode: t
 tooltip-mode: t
 mouse-wheel-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 unify-8859-on-encoding-mode: t
 utf-translate-cjk-mode: t
 auto-compression-mode: t
 temp-buffer-resize-mode: t
 line-number-mode: t
 transient-mark-mode: t

Recent input:
? <return> M-< C-n C-k C-k <switch-frame> <switch-frame> 
<switch-frame> C-y <switch-frame> <next> <down> <down> 
<down> <up> <up> <up> <up> <up> <up> <up> <up> p <switch-frame> 
<switch-frame> <switch-frame> <down-mouse-2> <mouse-2> 
<backspace> C-j C-x 4 C-f . e m <tab> <return> C-s 
v m - s p o o M-< C-x C-f . v m C-g C-x C-f ~ / . v 
m <return> C-s C-g C-_ C-s v m - s p o o l - f i l 
e s C-a ; C-x C-s <help-echo> <switch-frame> <switch-frame> 
q <switch-frame> C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-c C-g <switch-frame> <help-echo> 
<help-echo> C-x M q q <help-echo> C-x M n n n n n n 
n M-< C-s S E C C-a SPC <switch-frame> <help-echo> 
C-x C-f ~ / N <tab> <return> C-x c C-a C-k r p m g 
r e p SPC l h a <return> ! <help-echo> <help-echo> 
<switch-frame> <switch-frame> <help-echo> <switch-frame> 
<switch-frame> <help-echo> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <help-echo> <switch-frame> 
d <switch-frame> <help-echo> C-u C-u C-u <f6> C-x o 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p M-> 
C-x o C-x C-f <M-backspace> <M-backspace> u p d <return> 
<help-echo> <switch-frame> M-> C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p SPC n n d d d e <next> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <left> = C-c C-c 
SPC SPC <backspace> <backspace> <down-mouse-2> <mouse-2> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
n <down-mouse-2> <mouse-2> s I <tab> <return> q d SPC 
<switch-frame> M-x r e p o <tab> r <tab> <return>

Recent messages:
End of message 1059 from Göran Uddeborg
Loading vm-digest...done
Decoding MIME message... done
End of message 1 from Gunilla Christensson
1 message saved to buffer INBOX
Quitting...
Decoding MIME message... done
End of message 1060 from Göran Uddeborg
Making completion list...
Loading emacsbug...done

Message #10 received at 38-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Göran Uddeborg <goeran <at> uddeborg.se>
Cc: bug-gnu-emacs <at> gnu.org, 38-done <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 00:40:29 +0000

Version: 22.1.92

Göran Uddeborg wrote:
> It seems there is no coding system applied to values of environment
> variables.
>   

Thank you for your report. This should be now fixed for 22.2.

Message #11 received at 38-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: Göran Uddeborg <goeran <at> uddeborg.se>,
        bug-gnu-emacs <at> gnu.org, 38-done <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 11:22:03 +0900

>>>>> On Wed, 05 Mar 2008 00:40:29 +0000, Jason Rumney <jasonr <at> gnu.org> said:

> Version: 22.1.92 Göran Uddeborg wrote:
>> It seems there is no coding system applied to values of environment
>> variables.
>> 

> Thank you for your report. This should be now fixed for 22.2.

I think you mean the latest changes for fileio.c below:

2008-03-05  Jason Rumney  <jasonr <at> gnu.org>

        * fileio.c (Fexpand_file_name): Decode home directory names.
        (Fsubstitute_in_file_name): Decode substituted variables.

But I'd strongly suggest to revert this changes at this timing of
pretest for upcoming Emacs 22.2.  First, some coding systems are not
ready until some .elc files get loaded (a chicken-and-egg problem).
Second, as DECODE_FILE causes GC and string compaction in general,
some variables such as `nm' in Fexpand_file_name may not point to
valid data after that.  You may also want to see a related patch in
http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #16 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Göran Uddeborg <goeran <at> uddeborg.se>,
        bug-gnu-emacs <at> gnu.org, 38 <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 08:57:31 +0000

YAMAMOTO Mitsuharu wrote:
> 2008-03-05 Jason Rumney <jasonr <at> gnu.org>
>         * fileio.c (Fexpand_file_name): Decode home directory names.
>         (Fsubstitute_in_file_name): Decode substituted variables.
>
> But I'd strongly suggest to revert this changes at this timing of
> pretest for upcoming Emacs 22.2.

It fixes a serious bug. Users with non-ASCII names in their user names 
get strange behaviour of filename expansion.

>   First, some coding systems are not
> ready until some .elc files get loaded (a chicken-and-egg problem).
>   

It should not present a chicken and egg problem, as no files are loaded 
during bootstrap that require expansion of ~ or environment variables.

> Second, as DECODE_FILE causes GC and string compaction in general,
> some variables such as `nm' in Fexpand_file_name may not point to
> valid data after that.

This is a problem on some systems that still do not support stack 
marking for GC protection of such variables. But I think this bug is 
important enough to fix those problems rather than revert the patch.

>   You may also want to see a related patch in
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
>   

Was there a problem with that patch? Why was it not installed at the time?

Message #21 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: Göran Uddeborg <goeran <at> uddeborg.se>,
        bug-gnu-emacs <at> gnu.org, 38 <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 18:16:45 +0900

>>>>> On Wed, 05 Mar 2008 08:57:31 +0000, Jason Rumney <jasonr <at> gnu.org> said:

> YAMAMOTO Mitsuharu wrote:
>> 2008-03-05 Jason Rumney <jasonr <at> gnu.org> * fileio.c
>> (Fexpand_file_name): Decode home directory names.
>> (Fsubstitute_in_file_name): Decode substituted variables.
>> 
>> But I'd strongly suggest to revert this changes at this timing of
>> pretest for upcoming Emacs 22.2.

> It fixes a serious bug. Users with non-ASCII names in their user
> names get strange behaviour of filename expansion.

I know, but your patch has a serious problem and leads to regression.

>> First, some coding systems are not ready until some .elc files get
>> loaded (a chicken-and-egg problem).
>> 

> It should not present a chicken and egg problem, as no files are
> loaded during bootstrap that require expansion of ~ or environment
> variables.

I meant the startup of the dumped executable.  Users may set
EMACS_LOAD_PATH and so on.

>> Second, as DECODE_FILE causes GC and string compaction in general,
>> some variables such as `nm' in Fexpand_file_name may not point to
>> valid data after that.

> This is a problem on some systems that still do not support stack
> marking for GC protection of such variables. But I think this bug is
> important enough to fix those problems rather than revert the patch.

Relocation of string data caused by GC has nothing to do with
(semi-obsolete) GCPROs.  Believe me, it causes a real problem.

>> You may also want to see a related patch in
>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
>> 

> Was there a problem with that patch? Why was it not installed at the time?

Because no expert in this area made a response about the patch.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #30 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Göran Uddeborg <goeran <at> uddeborg.se>,
        bug-gnu-emacs <at> gnu.org, 38 <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 10:11:42 +0000

YAMAMOTO Mitsuharu wrote:

>> Was there a problem with that patch? Why was it not installed at the time?
>>     
>
> Because no expert in this area made a response about the patch.
>   

OK, I reverted my change. I'll let Chong and Stefan decide whether to 
fix the bug with your safer patch now (and a similar patch for 
Fsubstitute_in_file_name) or release 22.2 with this as a known bug.

Message #35 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, bug-gnu-emacs <at> gnu.org,
        38 <at> debbugs.gnu.org,
        Göran Uddeborg <goeran <at> uddeborg.se>
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 11:34:53 +0100

Jason Rumney <jasonr <at> gnu.org> writes:

> YAMAMOTO Mitsuharu wrote:
>> Second, as DECODE_FILE causes GC and string compaction in general,
>> some variables such as `nm' in Fexpand_file_name may not point to
>> valid data after that.
>
> This is a problem on some systems that still do not support stack marking
> for GC protection of such variables. But I think this bug is important
> enough to fix those problems rather than revert the patch.

Only Lisp_Object variables are protected.  Failing to protect
non-Lisp_Object pointers can result in crashes.  A crash is always the
worst possible problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #40 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: jasonr <at> gnu.org
Cc: goeran <at> uddeborg.se, bug-gnu-emacs <at> gnu.org, 38 <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 20:00:15 +0900 (JST)

>>>>> On Wed, 05 Mar 2008 10:11:42 +0000, Jason Rumney <jasonr <at> gnu.org> said:

>>> Was there a problem with that patch? Why was it not installed at
>>> the time?
>> 
>> Because no expert in this area made a response about the patch.

> OK, I reverted my change. 

Thanks.

> I'll let Chong and Stefan decide whether to fix the bug with your
> safer patch now (and a similar patch for Fsubstitute_in_file_name)
> or release 22.2 with this as a known bug.

I understand the bug is annoying on certain environments, but I would
like to defer any kinds of fixes for this bug to later versions, as
the fixes involve nontrivial issues and may affect in unexpected ways.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #45 received at 38-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Jason Rumney <jasonr <at> gnu.org>, bug-gnu-emacs <at> gnu.org,
        GFFFFFFran Uddeborg <goeran <at> uddeborg.se>,
        38-done <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 05 Mar 2008 11:25:59 -0500

> But I'd strongly suggest to revert this changes at this timing of
> pretest for upcoming Emacs 22.2.  First, some coding systems are not
> ready until some .elc files get loaded (a chicken-and-egg problem).
> Second, as DECODE_FILE causes GC and string compaction in general,
> some variables such as `nm' in Fexpand_file_name may not point to
> valid data after that.  You may also want to see a related patch in
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html

How 'bout installing this change on the trunk?


        Stefan

Message #46 received at 38-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Jason Rumney <jasonr <at> gnu.org>, bug-gnu-emacs <at> gnu.org,
        Göran Uddeborg <goeran <at> uddeborg.se>,
        38-done <at> debbugs.gnu.org
Subject: Re: No coding system used for environment variables
Date: Fri, 07 Mar 2008 21:12:35 +0900

>>>>> On Wed, 05 Mar 2008 11:25:59 -0500, Stefan Monnier <monnier <at> iro.umontreal.ca> said:

>> But I'd strongly suggest to revert this changes at this timing of
>> pretest for upcoming Emacs 22.2.  First, some coding systems are
>> not ready until some .elc files get loaded (a chicken-and-egg
>> problem).  Second, as DECODE_FILE causes GC and string compaction
>> in general, some variables such as `nm' in Fexpand_file_name may
>> not point to valid data after that.  You may also want to see a
>> related patch in
>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html

> How 'bout installing this change on the trunk?

While I was looking at the code of Fsubstitute_in_file_name to
make the patch for the trunk, I noticed that it contains a danger
of destination buffer shortage in both the EMACS_22_BASE branch
and the trunk.

*** src/fileio.c.~1.580.2.10.~	Thu Mar  6 09:44:27 2008
--- src/fileio.c	Fri Mar  7 20:55:26 2008
***************
*** 2227,2233 ****
  	o = (unsigned char *) egetenv (target);
  	if (o)
  	  {
! 	    total += strlen (o);
  	    substituted = 1;
  	  }
  	else if (*p == '}')
--- 2227,2238 ----
  	o = (unsigned char *) egetenv (target);
  	if (o)
  	  {
! 	    if (STRING_MULTIBYTE (filename))
! 	      /* A unibyte character may occupy 2 bytes when converted
! 		 to multibyte.  */
! 	      total += strlen (o) * 2;
! 	    else
! 	      total += strlen (o);
  	    substituted = 1;
  	  }
  	else if (*p == '}')

As I can't install it too soon, please install it to EMACS_22_BASE if
the next pretest is out shortly (and if the patch looks good, of
course.)

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #77 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        Jason Rumney <jasonr <at> gnu.org>
Cc: 38 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 23 Jul 2008 20:01:54 -0400

> It seems there is no coding system applied to values of environment
> variables.

What's the current situation with this bug?  Jason's patch was reverted,
but nothing else seems to have been done after that.

Two objections were made to Jason's patch: (i) some coding systems are
not ready until some .elc files get loaded (relevant for special cases,
such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
so variables such as `nm' in Fexpand_file_name may not point to valid
data after that.

If no elegant solution is forthcoming, I'd suggest simply documenting
(i) as a limitation, and dealing with (ii) by simply turning off GC in
the affected part of the function.

I noticed that the patch posted at

http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html

has not been checked into the trunk either.

Message #82 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        38 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: No coding system used for environment variables
Date: Thu, 24 Jul 2008 01:10:15 +0100

Chong Yidong wrote:
>> It seems there is no coding system applied to values of environment
>> variables.
> 
> What's the current situation with this bug?  Jason's patch was reverted,
> but nothing else seems to have been done after that.
> 
> Two objections were made to Jason's patch: (i) some coding systems are
> not ready until some .elc files get loaded (relevant for special cases,
> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
> so variables such as `nm' in Fexpand_file_name may not point to valid
> data after that.
> 
> If no elegant solution is forthcoming, I'd suggest simply documenting
> (i) as a limitation, and dealing with (ii) by simply turning off GC in
> the affected part of the function.

I think the GC part can be handled the same way as in bug #93

> I noticed that the patch posted at
> 
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
> 
> has not been checked into the trunk either.

I think the bug reported there is the same as #93, which is fixed in the
trunk, but not the branch AFAIK.

Message #87 received at 38 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        38 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: No coding system used for environment variables
Date: Wed, 23 Jul 2008 20:30:20 -0400

Jason Rumney <jasonr <at> gnu.org> writes:

>> Two objections were made to Jason's patch: (i) some coding systems are
>> not ready until some .elc files get loaded (relevant for special cases,
>> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
>> so variables such as `nm' in Fexpand_file_name may not point to valid
>> data after that.
>> 
>> If no elegant solution is forthcoming, I'd suggest simply documenting
>> (i) as a limitation, and dealing with (ii) by simply turning off GC in
>> the affected part of the function.
>
> I think the GC part can be handled the same way as in bug #93

Okay.  Could you put your patch back in, with the proper GC handling?

>> I noticed that the patch posted at
>> 
>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html
>> 
>> has not been checked into the trunk either.
>
> I think the bug reported there is the same as #93, which is fixed in the
> trunk, but not the branch AFAIK.

Could you port this fix to the branch?  Thanks.

Message #92 received at 38-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        38-done <at> debbugs.gnu.org
Subject: bug#38: Re: No coding system used for environment variables
Date: Tue, 24 Mar 2009 22:23:12 +0800

Chong Yidong wrote:
> Jason Rumney <jasonr <at> gnu.org> writes:
>
>   
>>> Two objections were made to Jason's patch: (i) some coding systems are
>>> not ready until some .elc files get loaded (relevant for special cases,
>>> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
>>> so variables such as `nm' in Fexpand_file_name may not point to valid
>>> data after that.
>>>
>>> If no elegant solution is forthcoming, I'd suggest simply documenting
>>> (i) as a limitation, and dealing with (ii) by simply turning off GC in
>>> the affected part of the function.
>>>       
>> I think the GC part can be handled the same way as in bug #93
>>     
>
> Okay.  Could you put your patch back in, with the proper GC handling?
>   

I've finally looked at this, and the case for Fsubstitute_file_name 
looks much simpler than Fexpand_file was. Only one Lisp_String was 
internally referenced, and that was already copied on DOS_NT, so I moved 
the copy outside of the #ifdef so that all platforms now work with a 
copy of the original string.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.