From owner-freebsd-hackers Thu Feb 11 15:40:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06058 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 15:40:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06053 for ; Thu, 11 Feb 1999 15:40:31 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40405>; Fri, 12 Feb 1999 10:29:55 +1100 Date: Fri, 12 Feb 1999 10:40:23 +1100 From: Peter Jeremy Subject: Re: portability of shm, mmap, pipes and socket IPC To: tlambert@primenet.com Cc: hackers@FreeBSD.ORG Message-Id: <99Feb12.102955est.40405@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Discussing semop(2) behaviour] Terry Lambert wrote: >What about a negative initial value setting? ... > When the man page says "absolute value", it *means* >"absolute value". The spec only refers to the absolute value of negative values of sem_op, ie (-sem_op). A negative initial value _shouldn't_ cause a problem (but see below), although I haven't confirmed this. I've been comparing the FreeBSD man page with Solaris 2.5, Digital UNIX 4.0D, Linux 0.99.13 and The Open Group's `Single Unix Specification, version 2' (http://www.opengroup.org/onlinepubs/7908799/xsh/semop.html). This reveals a number of typos in FreeBSD's man page: - there's a missing `absolute value' in the 2nd point covering negative sem_ops. - the description of behaviour when sem_op is zero is incomplete (no reference to IPC_NOWAIT or semzcnt). - the list of error returns is incomplete. There are a couple of areas of disagreement in the API: - TOG, Solaris and Linux define sem_num as `short', DEC and FreeBSD use u_short. - nsops is defined as size_t by DEC, TOG and Solaris, and unsigned by FreeBSD and Linux. I haven't been thru the code in detail, but I can immediately see the following problems: - if sem_op is 0, the process should only need READ permission on the semaphore. We currently require WRITE permission - there's no check on the range of semval (which should return ERANGE). This may be related to Terry's problem. I'll have a closer look at the code over the weekend (if I get time) and write a PR. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message