GNU bug report logs - #20822
environment mangled by locale

Previous Next

Full log

Message #23 received at 20822 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 20822 <at> debbugs.gnu.org, Zefram <zefram <at> fysh.org>, ludo <at> gnu.org
Subject: Re: bug#20822: environment mangled by locale
Date: Sat, 25 Jun 2016 21:10:48 -0400

Andy Wingo <wingo <at> pobox.com> writes:

> On Tue 16 Jun 2015 06:17, Zefram <zefram <at> fysh.org> writes:
>
>> When guile-2.0 is asked to read environment variables, via getenv,
>> it always decodes the underlying octet string according to the current
>> locale's nominal character encoding.  This is a problem, because the
>> environment variable's value is not necessarily encoded that way, and
>> may not even be an encoding of a character string at all.  The decoding
>> is lossy, where the octet string isn't consistent with the character
>> encoding, so the original octet string cannot be recovered from the
>> mangled form.  I don't see any Scheme interface that retrieves the
>> environment without locale decoding.
>
> Options:
>
>   Add optional "encoding" arg to scm_getenv; encoding is a string
>
>   Add alternate getenv interface that returns a bytevector
>
> We'll have to do the same for setenv too, I think.
>
> I think I would go with adding an encoding argument to getenv.  WDYT
> Mark and Ludovic?

I just don't see how this could be used sanely in actual practice.
These things are conceptually strings, and by convention they are
supposed to encoded in the locale encoding.  If that convention is
violated, I don't see what a program could do about it.

Can someone show me a realistic example of how this would be used in
practice?

      Mark

Previous Next

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