Custom Query (1030 matches)

Read-char-no-hang is supposed to return NIL if there is no more input available from the stream. But it hangs in the following particular example, when it's trying to read from the output stream of an external program, and that stream is still open but there's nothing on it:

? (defparameter *cat-process*
    (run-program "cat" nil
               :input :stream
               :output :stream
               :wait nil))
*CAT-PROCESS*
? (write-line "hi" (external-process-input-stream *cat-process*))
"hi"
? (finish-output (external-process-input-stream *cat-process*))
NIL
? (read-char-no-hang (external-process-output-stream *cat-process*))
#\h
? (read-char-no-hang (external-process-output-stream *cat-process*))
#\i
? (read-char-no-hang (external-process-output-stream *cat-process*))
#\Newline
? (read-char-no-hang (external-process-output-stream *cat-process*))
;; (hangs)

Another strange thing about the same situation is that LISTEN on that stream returns T even when there's no more to be read.

When used on macros, ccl:arglist interns symbols from the lambda list into the current package:

(defpackage :foo (:use :cl))
#<Package "FOO">
? (in-package :foo)
#<Package "FOO">
? (defmacro bar (bar10))
;Compiler warnings :
;   In BAR: Unused lexical variable BAR10
BAR
? (in-package :cl-user)
#<Package "COMMON-LISP-USER">
? (find-symbol "BAR10")
NIL
NIL
? (ccl:arglist 'foo::bar t)
(BAR10)
:DECLARATION
? (find-symbol "BAR10")
BAR10
:INTERNAL

I've discovered multiple problems in ARM FFI while trying to run CFFI test suite.

1. There was a stray apostrophe in lib/ffi-linuxarm.lisp in arm-linux::generate-callback-bindings which caused problems with compilation. Fixed in the patch.

2. There was an error in s8->fixnum vinsn (val / result confusion, shift in the wrong direction). Attached charfail.lisp demonstrates the problem. Fixed in the patch.

3. There was a problem in mem-set-c-single-float / mem-set-single-float, val/src confusion that didn't seem to affect anything most of the time by pure accident plus bad index reference in mem-set-single-float. This is demonstrated by the second assert in attached floatfail.lisp. Fixed in the patch.

4. There is still a problem with mem-set-c-double-float, mem-set-double-float, get-double, get-double? and maybe other functions. Besides ignoring val and using src instead in mem-set(-c)-double-float, there's a more serious problem that I was unable to fix.

Namely, these functions use explicit register specifications for their temps that are used for strd/ldrd instructions that need consective registers. This seems to break register handling somehow, as the following can be observed at the end of disassembly of my-mem-set-double-float in attached floatfail.lisp:

  (ldrd imm0 (:@ arg_z (:$ 2)))
  (fmdrr d0 imm0 imm1)
  (add nargs imm0 imm1)
  (fmrrd imm0 imm1 d0)
  (strd imm0 (:@ nargs (:$ 0)))
  (ldmia (:! sp) (imm0 vsp fn pc))

Here we see imm0 and imm1 getting destroyed by get-double vinsn and later being used to construct address for the following strd as if nothing happened. This leads to memory fault.

The possible workaround is not using strd/ldrd at all but perhaps it's also possible to fix temp handling, but I don't have time to do it myself right now.