[Ecls-list] Signed character lossage

[Andy Hefner]

After a two month hiatus from work with ECL I've just updated from git
to try out the latest changes. To my relief, my app compiles and runs,
or at least parts of it do. I've run into a slight problem that didn't
occur in the past pertaining to characters. In several places I use
character code #xB3, the "cubed" superscript. In some places I've
typed it directly into strings in the source code (which I load in
latin-1 encoding), in other places I insert it via ~C and (code-char
#xB3) in format. Curiously it's these latter instances that have
broken. What appears to happen, if I print the character codes in the
resulting string out before where the program crashes, is that where I
expect to see code B3 I instead see -4D, suggesting somewhere a C char
type is being used where unsigned char might be more appropriate.
Here's a test which exhibits the problem if compiled but not
interpreted:

(defun testme ()
  (declare (optimize (debug 3)))
  (let* ((cubed (code-char #xB3))
         (string (format nil "Foo ~C~C" cubed (code-char #xB3))))
    (print (type-of string))
    (print (list :hex-characters (write-to-string (map 'list
'char-code string) :base 16)))
    (print string)))

In my application's code I could work around it by adding the extra
'cubed' variable rather than using the code-char call as an argument
directly to format - there, it seems to inhibit some transformation
done by the compiler  - but it doesn't seem to make any difference in
this test.

This snippet of generated code for my test function is interesting:
                {char V2;
                    V2= 179;
                    {char V3;
                        V3= 179;
                        V1=
cl_format(4,Cnil,_ecl_static_0,CODE_CHAR(V2),CODE_CHAR(V3)) /*  FORMAT
*/;}}

In the instance where it works in my application, I notice the
generated C is something like "cl_object V15 = CODE_CHAR(179)"
instead, which would stop the 179 from being interpreted as signed and
becoming a negative number. Also, strangely, I've intermittently had
unexpected success with both my application and the above test
function, where on certain compiles I'd get the expected character
code, just to have it break again on a later compile, and it isn't
clear to me why the compiler would've done anything different.