Re: Guile 2.0.0 cannot open /dev/urandom

[Andy Wingo]

Hi Martin,

On Thu 17 Feb 2011 23:58, Martin Ward <address@hidden> writes:

> scheme@(guile-user)> (open-input-file "/dev/urandom")
> ERROR: In procedure open-file:
> ERROR: In procedure fport_end_input: Invalid argument

Good catch!

The relevant part of the C backtrace is:

    #22 0x00007ffff7cd83f6 in scm_syserror (subr=0x7ffff7d8008e 
"fport_end_input") at error.c:177
    #23 0x00007ffff7ce174c in fport_end_input (port=<value optimized out>, 
offset=<value optimized out>) at fports.c:838
    #24 0x00007ffff7ce1817 in fport_seek (port=<value optimized out>, 
offset=<value optimized out>, 
        whence=<value optimized out>) at fports.c:709
    #25 0x00007ffff7d13d65 in scm_seek (fd_port=0x118cec0, offset=0x2, 
whence=<value optimized out>) at ports.c:1768
    #26 0x00007ffff7d1f5a9 in scm_i_scan_for_encoding (port=0x118cec0) at 
read.c:1672
    #27 0x00007ffff7ce250b in scm_open_file (filename=0x11659e0, mode=0x7676c0) 
at fports.c:463

It seems that Guile is scanning the first few lines of the file for a
"coding" declaration.  This is because it is being opened in textual
mode; if you open with (open-file "/dev/urandom" "rb") you will probably
get what you want.

It should not be erroring out here.  In fact the error appears to
proceed from an attempt to seek in the port after reading out the first
N bytes to scan them for a coding directive; hummm.  Mike, it seems that
we should unget bytes onto the port instead of seeking; does that sound
right to you?

Martin, note that with Guile 1.8 and earlier, byte IO masquerading as
character IO was all you have.  Now with 2.0 you really want to be
dealing with binary ports and bytevectors and such.

Thanks for the report,

Andy
-- 
http://wingolog.org/