Re: [STUMP] c-string decoding error (:external-format :UTF-8): the octet sequence 1 cannot be decoded.

[David Hansen]

On Fri, 27 Oct 2006 00:50:51 +0200 David Hansen wrote:

> I had a small look at the problem.  This happens when SBCL
> reads the environment before starting the process.

OK, now I'm pretty sure that it is a SBCL bug.  As far as i
understand `sb-posix:putenv' is the problem.  My man page of
putenv says:


       The libc4 and libc5 and glibc 2.1.2 versions conform to  SUSv2:
       the  pointer  string given to putenv() is used.  In particular,
       this string becomes part of the environment; changing it  later
       will  change the environment.  (Thus, it is an error is to call
       putenv() with an  automatic  variable  as  the  argument,  then
       return  from the calling function while string is still part of
       the environment.)  However, glibc 2.0-2.1.1 differs: a copy  of
       the string is used.  On the one hand this causes a memory leak,
       and on the other hand it violates SUSv2. This has been fixed in
       glibc2.1.2.


and i think SBCL does not pass a copy to the putenv function
(though i might be wrong).  A quick test showed that a simple
call to sb-posix:putenv adds garbage to the environment.
Whenever sb-ext:run-program is called the environment is
read and encoded to UTF-8 (one might call this a bug too, at
least i don't see any need in interpreting the environment if
one just want to copy it).  That's where the nasty error
message in stumpwm comes from.

SBCL stumpwm users can workaround this by making sure that
DISPLAY is set when starting SBCL/stumpwm.  stumpwm won't
touch the environment then.

xpost to the sbcl devels

David