February 2013 - cmucl-ticket - mailman3.common-lisp.net

Re: [cmucl-ticket] [cmucl] #74: utf-8 bug in compile-file
by cmucl 27 Feb '13

27 Feb '13

#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.

1 0

Re: [cmucl-ticket] [cmucl] #74: utf-8 bug in compile-file
by cmucl 27 Feb '13

27 Feb '13

#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.

1 0

[cmucl-ticket] [cmucl] #73: Signal errors when modifying the standard readtable or standard pprint dispatch table
by cmucl 24 Feb '13

24 Feb '13

#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.

1 1

[cmucl-ticket] [cmucl] #72: SIGFPE with no exceptions currently enabled?
by cmucl 01 Feb '13

01 Feb '13

#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.

1 1