SBCL 1.0.25 +thread +unicode
Mac OS X 10.5.6
I have just spent a while tracking down a bizarre interaction between
SBCL (1.0.25), portable aserve (portableaserve-1.2.47-vbz-0.1.4) and
the display of floating point numbers.
I'm not sure if this is the correct mailing list, but I figured at
least somebody here would know where this might need to go.
The issue was that when running Portable Aserve, the display of
floating point numbers was horribly corrupted when they were written
to the http response stream using PRINC, PRIN1 or the ~A or ~S FORMAT
directives. The ~F FORMAT directive did not display the problem.
I was able to track the problem down to a type-mismatch in the
declarations of the portable aserve code.
In the file "acl-compat/lw-buffering.lisp" (*), there is an implicit
assumption that all arguments of type STRING are also of type (ARRAY
CHARACTER). But unfortunately, a SIMPLE-BASE-STRING is not. And the
code that performs general formatting of floats returns the
representation as a SIMPLE-BASE-STRING. Since that is not a subtype
of (ARRAY CHARACTER), the code that proceeds to write the data gets
horribly confused and bizarre results appear.
Since the code is compiled with high speed and low safety, the type
mismatch is not detected at runtime.
It seems that the problem is limited to a single function definition,
namely WRITE-CHARS. I found that changing the type declaration from
(ARRAY CHARACTER) to STRING, I get correct results. I would expect
that this might have some performance implications, but it seems that
this is the only safe change to make.
I also tried turning unicode support on and off. It makes no
I'm also attaching a simple test file that will demonstrate the
problem in portable aserve. The URL served would appear at "http://localhost
:PORT/test/test.html" after you start the server normally on PORT.
(*) Despite the "lw" in the name, this file is loaded into SBCL.
> assumption that all arguments of type STRING are also of type (ARRAY
> CHARACTER). But unfortunately, a SIMPLE-BASE-STRING is not. And the code
unfortunately there are some libraries that assume this.
i'm running a locally modified sbcl whose reader reads in
simple-base-string's whenever possible. among our dependencies we had
two libs that choke on it, one was cl-l10n (due to a patch of mine,
*grin*) and the other one is cxml (i've sent a simple patch to the
list but i think it hasn't ben applied to the official yet).
this change has some effect on the image size also.