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

					+---+
					| +-+-+
					+-+-+ |
					  +---+