[Larceny-users] rem-ref! error when using unix pipes

[Will Donnelly]

Good evening all,

I think the behaviour I am seeing is a bug, although it is entirely possible
I am simply misunderstanding what is supposed to be occurring here.

Whenever a unix pipe is generated, the descriptors are opened as ports, and
the ports are transcoded, the file descriptors seem to be added to the
vector of open files in "src/Lib/Common/fileio.sch" twice, but are added to
the bag in "Standard/unix-descriptor" only once. Combined with the fact that
the "rem-ref!" function defined therein errors out when a given a
nonexistent descriptor, instead of returning #t as the comments say it
should, this causes an error easily reproduced by executing the following
code in ERR5RS mode:

--
(import (rnrs) (primitives r5rs:require unix/pipe open-output-descriptor
open-input-descriptor))
(r5rs:require "Standard/unix-descriptor")
(define pipe-ends (let-values (((r pipe-r pipe-w) (unix/pipe))) (cons
(open-input-descriptor pipe-r) (open-output-descriptor pipe-w))))
(define transcoded-pipe-ends (cons (transcoded-port (car pipe-ends)
(native-transcoder)) (transcoded-port (cdr pipe-ends) (native-transcoder))))
(exit)
--

Closing the ports does not help, as this will not remove the duplicate
references to the file descriptor, and it is only possible to remove the
first set before raising an error.

This issue can be worked around simply by modifying the "rem-ref!" function
in "Standard/unix-descriptor" to look like the following:

--
(define (rem-ref! fd) ;; returns #t if fd not in result bag.  O/w #f.
  (let loop ((l bag))
    (cond ((null? (cdr l)) #t)
          ((eqv? fd (cadr l))
           (set-cdr! l (cddr l))
       #f)
          (else (loop (cdr l))))))
--

... which does essentially the same thing as the current function, just
without the error and the (as far as I can tell) unnecessary call to "memv".

Hoping this issue can be resolved quickly,
Will Donnelly
-------------- next part --------------
HTML attachment scrubbed and removed