[Sbcl-devel] Re: SBCL 0.9.1 dumps core with unsupported locale

[<em...@te...>]

* Nikodemus Siivola <nik...@ra...>
... 
| In that case you can work around this by starting SBCL with eg.
| 
|   env LANG=C sbcl
| 
| (adjust LANG to suit, or use LC_CTYPE) -- of course this still keeps
| you restricted to external formats supported by SBCL till someone
| writes support for eucJP.

Something similar happens with a "supported" locale like
iso-8859-1. Transcription follows (more comments below):

$ uname -a
FreeBSD 5.3-SECURITY #0: Sat May  7 07:34:31 UTC 2005 ro...@bu...:/usr/obj/usr/src/sys/GENERIC  i386

$ locale -a | grep en_US
en_US.ISO8859-1
en_US.ISO8859-15
en_US.US-ASCII
en_US.UTF-8

$ set | egrep 'LANG|LC'
LANG=en_US.ISO8859-1
LC_COLLATE=POSIX

$ sbcl --noinform --userinit /dev/null --eval '(progn
(format t "~A ~C~%" (lisp-implementation-version)(code-char
241))(quit))'
0.8.17 ñ

$ /opt/bin/sbcl --core /opt/lib/sbcl/sbcl.core --noinform
--userinit /dev/null --eval '(progn (format t "~A ~C~%"
(lisp-implementation-version)(code-char 241))(quit))'
0.8.21 ñ

$ src/runtime/sbcl --core output/sbcl.core --noinform
--userinit /dev/null --eval '(progn (format t "~A ~C~%"
(lisp-implementation-version)(code-char 241))(quit))'
Segmentation fault # this is in fact 0.9.1

$ export LANG=en_US.UTF-8

$ sbcl --noinform --userinit /dev/null --eval '(progn
(format t "~A ~C~%" (lisp-implementation-version)(code-char
241))(quit))'
0.8.17 ñ

$ src/runtime/sbcl --core output/sbcl.core --noinform
--userinit /dev/null --eval '(progn (format t "~A ~C~%"
(lisp-implementation-version)(code-char 241))(quit))'
0.9.1 ñ

$ export LANG=ISO-8859-1

$ src/runtime/sbcl --core output/sbcl.core --noinform
--userinit /dev/null --eval '(progn (format t "~A ~C~%"
(lisp-implementation-version)(code-char 241))(quit))'
0.9.1
debugger invoked on a SIMPLE-ERROR in thread 79935:
  Error during processing of --eval option "(progn (format t
\"~A ~C~%\" (lisp-implementation-version)(code-char
241))(quit))":

  encoding error on stream #<SB-SYS:FD-STREAM for "standard
  output" {480015C1}>
  (:EXTERNAL-FORMAT :ASCII):
    the character with code 241 cannot be encoded.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from
SBCL.

restarts (invokable by number or by possibly-abbreviated
name):
  0: [OUTPUT-NOTHING] Skip output of this character.
  1: [CONTINUE      ] Ignore and continue with next --eval
option.
  2: [ABORT         ] Skip rest of --eval options.
  3:                  Skip to toplevel READ/EVAL/PRINT loop.
  4: [QUIT          ] Quit SBCL (calling #'QUIT, killing the
process).

((LAMBDA (SB-IMPL::E)) #<SB-INT:STREAM-ENCODING-ERROR
{48008861}>)
0]

Seems that my terminal isn't UTF-8 enabled so it prints 'ñ'
instead of 'ñ'. The main point (I think) is that the
missmatch betwen ISO8859-1 and ISO-8859-1 leads to a
segfault or a fallback to US-ASCII in 0.9.1. And although
UTF is sexy and all, I'm not about to change all my source
files to UTF-8 for the time being.

Cheers,

-- 
Eduardo Muñoz          | (prog () 10 (print "Hello world!")
http://213.97.131.125/ |          20 (go 10))