Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!mtune!codas!cpsc6a!rtech!wrs!dg From: dg@wrs.UUCP (David Goodenough) Newsgroups: comp.lang.c Subject: Re: Weird syscall returns Message-ID: <235@wrs.UUCP> Date: Sun, 12-Jul-87 16:08:53 EDT Article-I.D.: wrs.235 Posted: Sun Jul 12 16:08:53 1987 Date-Received: Tue, 14-Jul-87 02:12:58 EDT References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <2337@whuts.UUCP> <428@sds.SciCom.MN.ORG> Reply-To: dg@wrs.UUCP (David Goodenough) Organization: Wind River Systems, Emeryville, CA Lines: 63 In article <428@sds.SciCom.MN.ORG> dave@sds.SciCom.MN.ORG (dave schmidt x194) writes: >> I can think of no Unix system call that doesn't return -1 on error. > >What about nice()? Well I don't know about your system, but on ours (ISI 68K - BSD 4.3) there ain't no entry for nice in sect. 2 of the manual - it's in section 3. What this tells me is that nice(3) isn't a direct system call. In fact it goes via [sg]etpriority(2) which IS a system type call: witness the following - First comes foo.c main() { nice(); } and now comes the output from an 'adb foo' run _main: link fp,#0 jsr _nice ; call to nice(3) unlk fp rts _nice: link fp,#-4 clrl _errno pea 0:w pea 0:w jsr _getpriority ; call to getpriority(2) addql #8,sp . . . pea 0:w jsr _setpriority ; call to setpriority(2) lea sp@(12),sp unlk fp ; no traps (i.e. system entries) rts ; anywhere in nice .word 0 _getpriority: moveml sp@(4),#moveq #0x64,d0 trap #1 ; HERE is the system entry trap bccs 0xec jmp cerror rts _setpriority: moveml sp@(4),# moveq #0x60,d0 trap #1 ; and the other bccs 0x100 jmp cerror rts So order is restored!! -- dg@wrs.UUCP - David Goodenough +---+ | +-+-+ +-+-+ | +---+