(exit ...) should be unambiguous

[Derick Eddington]

[d@eep:~]-> ikarus
Ikarus Scheme version 0.0.2patched+ (revision 1242, build 2007-12-14)
Copyright (c) 2006-2007 Abdulaziz Ghuloum

> (exit 1)
[d@eep:~]-> echo $?
4

[Abdulaziz Ghuloum (aghuloum)]

Note that the exit status is not restricted to fixnums but can be any object. unfixing it will cause some ambiguous results. I don't care one way or the other (I only care about zero and not-zero cases). Does anybody else care?

[Derick Eddington (derick-eddington)]

I think it should conform to the C standard, the Scheme boolean
semantics, and on UNIXes, the common UNIX ability to use [0, 255]. So
that if the Scheme value supplied to the Scheme (exit <status>) is a:

integer, the unfixed value of the unsigned representation of the int
modulo 256 is the exit status.

#f, C's EXIT_FAILURE is the exit status.

not #f (any other object), C's EXIT_SUCCESS is the exit status.

This way, the cases where a specific exit number is required can be done
with Ikarus, and the Scheme boolean semantics of success and failure are
also available. If left ambiguous, then the meaning of the interaction
of (exit <status>) with the OS or parent process can only be understood
by knowing the low-level behind-the-scenes workings of fix-ed integers
and tagged pointers.

Chez, MzScheme, and Larceny have unambiguous exit statuses.

I like Chez's use of a parameter exit-handler which works with cafes,
but I also like the idea of the top cafe's default exit-handler using
Scheme boolean semantics with the two standard C EXIT_ statuses.

[Abdulaziz Ghuloum (aghuloum)]

> I think it should conform to the C standard, the Scheme boolean
> semantics, and on UNIXes, the common UNIX ability to use [0, 255].

Which C standard are you referring to here?

> So that if the Scheme value supplied to the Scheme (exit <status>)
> is a: integer, the unfixed value of the unsigned representation of
> the int modulo 256 is the exit status.

I couldn't find anywhere in the manuals that I have where it says
that that the exit status returned should be n modulo 256. So,
where did you read that?

[Derick Eddington (derick-eddington)]

I apologize if I came across weird by being overly pedantic. I was in
"assertions are just brainstorming" mode after thinking about what you
mentioned.

> Which C standard are you referring to here?
>

ANSI C. I said "conform" because I was thinking Ikarus's C code wants
to be as portable as reasonable, and ANSI C only provides EXIT_SUCCESS
and EXIT_FAILURE and that implies, although probably a non-existent
issue now days, EXIT_SUCCESS and EXIT_FAILURE are not necessarily 0 and
not-0.

Including the Scheme booleans and UNIX [0, 255] comments under "conform"
didn't make sense.

> I couldn't find anywhere in the manuals that I have where it says
> that that the exit status returned should be n modulo 256. So,
> where did you read that?
>

That was just my suggested idea so that exit numbers [0, 255] can be
used on OSes that support it. POSIX says the value of status & 0377 is
returned to the parent process, so I thought that should be supported on
POSIX systems.

The idea about also having the Scheme semantics of #f / not-#f
(excluding for integers) translate to EXIT_FAILURE and EXIT_SUCCESS
seemed like a natural fit.

[Abdulaziz Ghuloum (aghuloum)]

You see, there are too many problems with giving semantics to this
exit status. It's non-portable across operating systems, it's non-
portable across shells, and it's non-portable across Scheme
implementations. Ikarus should only make the two guarantees required
by R6RS:

(exit) => success status, i.e. 0
(exit #f) => failure status, i.e. non-0

If we guarantee more than that, and you rely on it, we will fail to
deliver sooner or later.

Now, I can "unfix" the number as you wanted if you really needed it
(I would like to know how you're using it), but do understand that
there are no guarantees for the behavior, neither on Ikarus across
OSes, nor across other Scheme implementations.

Aziz,,,

PS. I was told that I sound much louder in email than I do in real
life :-) Don't read my responses as though I was shouting.

[Abdulaziz Ghuloum (aghuloum)]

Changed behavior in revision 1258:

  the exit status due to calling (exit n) is
    : n if n is a fixnum
    : EXIT_FAILURE otherwise

[Derick Eddington (derick-eddington)]

I have no need for specific exit numbers presently. I was thinking if
anyone ever wanted to replace with an Ikarus version one of the programs
which use specific exit numbers to indicate something or if anyone
wanted to make a new Ikarus program which needs to be the child of a
parent which needs specific exit numbers, that it should be possible.

[Derick Eddington (derick-eddington)]

Just to be picky, since (exit) currently does (exit 0) to mean sucessful
exit, shouldn't ikrt_exit return EXIT_SUCCESS when the fixnum is 0,
because of the possibility of EXIT_SUCCESS not being 0? Or maybe,
(exit) does not do (exit 0), but instead ikrt_exit is given an
additional boolean argument especially for the (exit) case which
indicates EXIT_SUCCESS should be returned, and for the (exit <obj>) case
that new additional argument is false and if <obj> is a fixnum its
unfixed value is returned. Or maybe, put an (exit-i <fixnum>) in
(ikarus posix) and R6RS exit only does EXIT_SUCCESS for (exit) and
EXIT_FAILURE for all (exit <obj>). I like that last one best. These
would need to be changed:

ikarus.control.ss:135: [() (exit 0)]
ikarus.exceptions.ss:34: (exit -1)))))
ikarus.main.ss:97: (exit 0)]
ikarus.main.ss:102: (exit 0)]
ikarus.main.ss:108: (exit 0)])))

[Abdulaziz Ghuloum (aghuloum)]

> Just to be picky, since (exit) currently does (exit 0) to mean
> sucessful
> exit, shouldn't ikrt_exit return EXIT_SUCCESS when the fixnum is 0,
> because of the possibility of EXIT_SUCCESS not being 0?

As you said, you're being picky :-)

You're right of course, there is a possibility of EXIT_SUCCESS not
being 0. The probability of that happening in the next, say, 100
years on any of the currently supported systems is far less than the
probability of a nuclear meltdown in which Ikarus and all such
operating systems evaporate and turn to dust. So, between now and
the upcoming nuclear winter, I say we should worry about the more
important things first :-)

Now do I have to justify why I'm not going to take any action
regarding the possibility of EXIT_SUCCESS not being zero? Or would
you just trust me on this one?

[Abdulaziz Ghuloum (aghuloum)]

This bug report is about to be closed as the fix comitted
previously will be incorporated in the next 0.0.3 release of
Ikarus Scheme, scheduled for January 31, 2008. A release
candidate tarball is available for download from:
http://www.cs.indiana.edu/~aghuloum/ikarus/ikarus-0.0.3-rc1.tar.gz
Please do test it if you have the time and report any issues
you might encounter. Thank you very much for your support.
(Sorry for the duplicates; I'm updating every open bug.)