Steel Bank Common Lisp

Richard M Kreuter <kreuter@...> writes:

> Can anybody say what's going wrong in this code?
>
> (let* ((socket (make-instance 'sb-bsd-sockets:inet-socket
> 			      :type :stream :protocol :tcp))
>        (stream (sb-bsd-sockets:socket-make-stream socket
> 						  :input t :output t)))
>   (format t ">> ~S~%" (ignore-errors (pathname stream)))
>   (if (ignore-errors (pathname stream))
>       :pathname
>       :no-pathname))
>>> NIL
> :PATHNAME

Fixed in 0.9.15.13, thanks for the report.

(PATHNAME was UNSAFELY-FLUSHABLE, so the call was elided.)

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

Nikodemus Siivola <nikodemus@...> writes:

> Richard M Kreuter <kreuter@...> writes:
>
>> Can anybody say what's going wrong in this code?
>>
>> (let* ((socket (make-instance 'sb-bsd-sockets:inet-socket
>> 			      :type :stream :protocol :tcp))
>>        (stream (sb-bsd-sockets:socket-make-stream socket
>> 						  :input t :output t)))
>>   (format t ">> ~S~%" (ignore-errors (pathname stream)))
>>   (if (ignore-errors (pathname stream))
>>       :pathname
>>       :no-pathname))
>>>> NIL
>> :PATHNAME
>
> Fixed in 0.9.15.13, thanks for the report.
>
> (PATHNAME was UNSAFELY-FLUSHABLE, so the call was elided.)

I don't understand this.  Firstly, I don't understand why the call can
ever be elided, since the result is being used; secondly, what is the
difference between PATHNAME and all the other UNSAFELY-FLUSHABLE
functions we have?

Consider
  (defun foo (x)
    (format t "~S~%" (ignore-errors (pathname x)))
    (if (ignore-errors (pathname x)) :pathname :no-pathname))
and
  (defun bar (x)
    (format t "~S~%" (ignore-errors (package-name x)))
    (if (ignore-errors (package-name x)) :package :no-package))

I can trigger Richard's bug with 
  (foo sb-sys::*tty*)
but not with
  (bar "DOES-NOT-EXIST")
and I don't know why.

Cheers,

Christophe

Christophe Rhodes <csr21@...> writes:

>> (PATHNAME was UNSAFELY-FLUSHABLE, so the call was elided.)
>
> I don't understand this.  Firstly, I don't understand why the call can
> ever be elided, since the result is being used; 

My impression is that it was being elided because the result value of
PATHNAME is always known to be true -- so first the second leg of IF is
deleted, at which point the return value isn't used anymore.

...but I didn't look at what it _really_ happening at IR. Obviously
something more complicated then that.

> secondly, what is the difference between PATHNAME and all the other
> UNSAFELY-FLUSHABLE functions we have?

PACKAGE-NAME has a known return type of (OR SIMPLE-STRING NULL), so
the IF remains intact? MERGE-PATHNAMES seems to exhibit the same
behaviour, and has an analogous DEFKNOWN.

> Consider
>   (defun foo (x)
>     (format t "~S~%" (ignore-errors (pathname x)))
>     (if (ignore-errors (pathname x)) :pathname :no-pathname))
> and
>   (defun bar (x)
>     (format t "~S~%" (ignore-errors (package-name x)))
>     (if (ignore-errors (package-name x)) :package :no-package))
>
> I can trigger Richard's bug with 
>   (foo sb-sys::*tty*)
> but not with
>   (bar "DOES-NOT-EXIST")
> and I don't know why.

It gets even "better": (foo nil) works, unlike (foo sb-sys::*tty*) !!

(Pre 0.9.15.13, that is, 0.9.15.13 exhibits the same with MERGE-PATHNAMES.)

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

Nikodemus Siivola <nikodemus@...> writes:

> ...but I didn't look at what it _really_ happening at IR. Obviously
> something more complicated then that.

The call indeed does get eventually flushed by FLUSH-DEAD-CODE, because
IR1-OPTIMIZE-IF calls FLUSH-DEST on the test-node whenever it is able
to delete either leg.

> It gets even "better": (foo nil) works, unlike (foo sb-sys::*tty*) !!

This happens because IR1-CONVERT-COMBINATION-CHECKING-TYPE adds a cast
to the know argument type for PATHNAME/MERGE-PATHNAMES, and the cast
remains even after the call has been flushed.

So, the question is, is IR1-OPTIMIZE-IF right? I think it is, as I don't see
how to trigger a bogus deletion of userland-code, but I'm not 100% sure.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."