#74: utf-8 bug in compile-file
-------------------------+--------------------------------------------------
Reporter: avodonosov | Owner:
Type: defect | Status: closed
Priority: major | Milestone:
Component: Unicode | Version: 20d
Resolution: fixed | Keywords:
-------------------------+--------------------------------------------------
Changes (by toy.raymond@…):
* status: new => closed
* resolution: => fixed
Comment:
commit e8f64b3f83455a82edad394c472481fadde6ccb5
Author: Raymond Toy <toy.raymond(a)gmail.com>
Date: Tue Feb 26 20:44:18 2013 -0800
Fix ticket:74
When accounting for the octets left in the in-buffer that we haven't
read (or converted to characters), we were subtracting the index from
the total in-buffer length. This is wrong if the file is less than
the total in-buffer length. We should have subtracted from the actual
number of octets in the in-buffer.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/74#comment:2>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#74: utf-8 bug in compile-file
------------------------+---------------------------------------------------
Reporter: avodonosov | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Unicode | Version: 20d
Keywords: |
------------------------+---------------------------------------------------
Comment(by rtoy):
Thanks for the detailed report. It appears to be a bug in file-position.
Unicode buffering is quite messy so it will take a bit of time to work
this out.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/74#comment:1>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#73: Signal errors when modifying the standard readtable or standard pprint
dispatch table
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2013-02
Keywords: |
--------------------+-------------------------------------------------------
Fare requested that errors be signaled when modifying the standard
readtable and pprint dispatch table. Conforming programs are forbidden to
modify them anyway.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/73>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#72: SIGFPE with no exceptions currently enabled?
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2013-01
Keywords: |
--------------------+-------------------------------------------------------
While I've seen this SIGFPE issue before, I never tracked it down. Here
is a repeatable case (from Carl):
{{{
(defun test (x y)
(declare (optimize (speed 3) (safety 0))
(type (signed-byte 32) x y))
(the (signed-byte 32) (truncate x y)))
}}}
Although the code lies to the compiler (the asserted return type of
{{{truncate}}} is incorrect), the point is that {{{(test #x-80000000
-1)}}} causes the SIGFPE exception.
I believe {{{sigfpe-handler}}} was only expecting to handle FP exceptions.
In this example, the division causes an overflow which generates the
SIGFPE.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/72>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#65: Different results for {{{expt}}} between compiled and interpreted code
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2012-12
Keywords: |
--------------------+-------------------------------------------------------
Consider
{{{
(defun sqr (x)
(declare (type (complex double-float) x))
(expt x 2))
}}}
Compare the results:
{{{
* (sqr #c(0d0 1d0))
#C(-1d0 0d0)
* (expt #c(0d0 1d0))
#C(-1.0d0 1.2246467991473532d-16)
}}}
The difference is caused by a deftransform for {{{expt}}} that converts
{{{(expt x 2)}}} to {{{(* x x)}}}.
Perhaps the {{{expt}}} should be modified to do the same transformation
when the power is one of the special values in the deftransform? (The
deftransform handles 2, 3, 4, and 1/2.)
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/65>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#71: NOT-MORE-CONTAGIOUS broken for double-double-floats
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2013-01
Keywords: |
--------------------+-------------------------------------------------------
Here is an example of the brokenness:
{{{
(defun foo (x)
(declare (type double-float x))
(expt x 2w0))
(compile 'foo)
(foo 2d0)
Invalid number of arguments: 1
[Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
}}}
This is a bug in {{{NOT-MORE-CONTAGIOUS}}} returning the wrong value. The
power should cause result of {{{EXPT}}} to be a double-double-float, but
the the deftransform just converts the call to a multiplication of two
double-floats. This mismatch of the actual type and the derived type
confuses the compiler and causes the weird error.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/71>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#70: Source location error with a logical pathname default
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2013-01
Keywords: |
--------------------+-------------------------------------------------------
When ticket:69 is fixed, the same code will then generated the following
error:
{{{
Parse error in namestring: Illegal character for logical pathname:
#\/
/tmp/bar.lisp
^
[Condition of type LISP::NAMESTRING-PARSE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(LISP::LOGICAL-CHUNKIFY "/tmp/foo.lisp" 0 13)
Source: Error finding source: Parse error in namestring: Illegal character
for logical pathname:
#\/
target:code/pathname.lisp
^
0]
}}}
The first error message is ok. The error about finding the source happens
again because the source information is stored as a namestring which the
debugger uses to open the source file. However, it's merged with the
logical pathname in {{{*default-pathname-defaults*}}}, causing another
error because the search-list namestring is treated as a logical pathname
namestring.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/70>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#69: Error parsing ext-formats:unidata.bin
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2013-01
Keywords: |
--------------------+-------------------------------------------------------
Consider the following:
{{{
(setf (logical-pathname-translations "foo")
'(("**;*.*.*" "/tmp/**/*.*")))
(let ((*default-pathname-defaults* #p"foo:"))
(pathname "/tmp/bar.lisp"))
}}}
This causes an error:
{{{
Unable to display error condition:
File-error in function LISP::FIND-LOGICAL-HOST:
Logical host not yet defined: "EXT-FORMATS"
[Condition of type LISP::NAMESTRING-PARSE-ERROR]
}}}
This happens because CMUCL wants to look up some unicode property and
needs to load the unicode database from ext-formats:unidata.bin. Because
we use a namestring, this gets merged with {{{*default-pathname-
defaults*}}} and is incorrectly parsed as a logical pathname namestring.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/69>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#68: bit-bash-copy can't handle very large objects
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2012-12
Keywords: |
--------------------+-------------------------------------------------------
{{{BIT-BASH-COPY}}} takes bit indices as offsets for copying random
objects. This is very useful if we're copying bit-arrays or arrays with
elements smaller than a byte. However, when copying strings or arrays
with elements larger than a byte, the bit index exceeds 32 bits when the
index is near {{{MOST-POSITIVE-FIXNUM}}}.
{{{BIT-BASH-COPY}}} needs to be updated to handle this, or a {{{BYTE-BASH-
COPY}}} should be added to handle the case where the element size is at
least a byte in size.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/68>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.