Re: Crash in scm_boot_guile if stdin isn't open.

[Gary Houston <ghouston at arglist dot com>]

> From: Marius Vollmer <mvo@zagadka.ping.de>
> Date: 11 Mar 2000 23:58:21 +0100
> 
> Jon K Hellan <hellan@acm.org> writes:
> 
> > On Sat, Mar 11, 2000 at 06:06:29PM +0100, Marius Vollmer wrote:
> > 
> > > I think Guile should not produce a segmentation fault, but I also
> > > think that one never ever should expect a program to run with a
> > > invalid fd 0.  Instead, one should hook fd 0 to /dev/null or
> > > something.  The standard streams should always be valid (IMO).
> > 
> > Hmm. We'll probably do that as a workaround. But I don't think an
> > embedded interpreter should make assumptions about which streams are
> > valid.
> 
> Maybe.  But I think aborting when fd 0 is invalid is acceptable
> behaviour of libguile.  I think any Unix Program can make the
> assumption that when any of the standard file descriptors are open,
> they are used for their standard purpose.  Changing this would be like
> changing the prototype of main, in my view, or rather, giving another
> meaning to the environment variable HOME.
> 
> Thus, I would say that it is not safe to just close fd 0, because the
> next call to open might reuse it and then fd 0 is something completely
> different from stdin.  Likewise for 1 and 2.
> 
> I would not label the solution of pointing fd 0 at /dev/null as a work
> around.  You just can't hope to get away with making fd 0 invalid.

The behaviour of scm_fdopen is currently a bit flaky: if you give it
an invalid file descriptor it either creates a port, throws an error,
or hangs.  Since it's supposed to take a file descriptor and return a
port, I think it's reasonable that it throws an error if you give it a
number that's not a file descriptor.

However I'm inclined to agree that (attempting to) abort during
startup because file descriptor 0 is closed isn't really useful to
anybody.  What I'd expect is that reading from the default input port
would either throw an error or return EOF, but an embedded interpreter
doesn't need to read from default input when it starts up.