Subject: bug#38: Re: No coding system used for environment variables

From: Jason Rumney <[email-masked]>
Date: Tue, 24 Mar 2009 22:23:12 +0800

Chong Yidong wrote:
> Jason Rumney <[email-masked]> 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.