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

[Marius Vollmer <mvo at zagadka dot ping dot de>]

Gary Houston <ghouston@arglist.com> writes:

> From: Marius Vollmer <mvo@zagadka.ping.de>
> 
> > 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.

Yes.  I don't want to give the impression that I think nothing needs
to be fixed with Guile.  I see these issues

 - It must be made safe to throw errors during initialization, or at
   least during a `second stage' initialization.  We should probably
   arrange it so that the caller of scm_boot_guile (or some new
   function) can arrange to be notified of these errors.

   Incidentally, this might go well with a new interface for
   initializing Guile that can be used without disrupting the flow of
   control, i.e. can be used as a normal subroutine and after calling
   it, Guile is initialized.  I think someone has done the needed busy
   work for this already, like finding the stack boundaries on some
   platforms.

 - After thinking more about it, I would now say that, yes, Guile
   should be able to carry on when 0, 1, or 2 are invalid file
   descriptors.  The corresponding Scheme objects could be set to `#f'
   when one of the descriptors is EBADF.

   We need to be prepared for this, however.  What should happen when
   an error should be signaled about (current-error-port) not being a
   port?  Maybe it is better to try our best to have at least a
   useable (current-error-port), by opening /dev/console, or maybe
   even going to syslog.

 - However, I still think that it would be much more robust not to
   close fd 0 in the first place, even when Guile can handle this.

   What is the Gnome daemon facility doing with fds 1 and 2, actually?
   Do they get redirected into syslog or into a `Gnome Daemon Log'
   that the user can peruse?  I really don't like autistic programs.

> However I'm inclined to agree that (attempting to) abort during
> startup because file descriptor 0 is closed isn't really useful to
> anybody.

Yep, I'll changed my mind on this.

- Marius