false
foo=bar
echo $?
would print 1
Also fixed the long standing bug:
false
echo `echo $?`
would print 0
The exitstatus needs rethinking and rewriting. The trial and error method
is not very efficient
Instead of being a no-op, kn03_intr_enable() sets the sw copy of the
interrupt-enable mask *and* writes it into the IO asic intr-enable
register. Boot code sets the sw copy (kn03_tc_imask) to something
sane (KN03_IM0, with tc option slots turned off). Tested and works.
Interrupt code for other IOASIC machines should be redone so that
interrupts for devices are enabled by drivers, rather than by
cpu-specific boot code. Functions common to all IOASIC machines
(PSWARN?) should be done by asic_init().
Checked in without the above changes so that 3MAX+, MAXINE and 3MIN
interrupt-(enable,handle) can converge.
latter would lead to undefined symbols if DDB not defined.
(2) check for break on console, and therefore debugger entry (if ddb
in kernel) earlier, so that the device doesn't need to be open.
(3) return immediately after breaking into the debugger in comeint().
(4) only do the normal character input routine in comintr if receive
mask yeilds _EXACLTY_ LSR_RXRDY. if there's only a receive
error, or there's a receive error _and_ a received character,
do comeint().
(former two by me. latter two from Bob Baron <rvb@cs.cmu.edu>.)
reported this enhancement to fdlibm-comments, and got the following
reply:
Date: Thu, 11 May 1995 14:35:25 -0700
From: Kwok.Ng@Eng.Sun.COM (KC Ng)
To: fdlibm-comments@sunpro.Eng.Sun.COM, jtc@cygnus.com
Subject: Re: fdlibm 5.2: why do core functions use sqrt?
> I noticed that core (e_*.c) fdlibm functions like __ieee754_acos()
> ensure that they call sqrt() with arguments in range (x > 0), when
> they could call __ieee754_sqrt() directly.
>
> Since sqrt() does a lot more work (verifies x is in range, etc.) is
> there any reason for this? I'd think that calling __iee754_sqrt()
> would be more appropriate. ....
You are right. __ieee754_sqrt should be in use with e_*.c.
phil