Xref: utzoo comp.sys.att:5625 unix-pc.general:2310
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!njin!princeton!jonlab!jon
From: jon@jonlab.UUCP (Jon H. LaBadie)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Isn't it amazing what you find in the manuals?
Summary: lockf is a library interface, is it among the missing?
Keywords: locking manuals security disruption
Message-ID: <632@jonlab.UUCP>
Date: 23 Feb 89 13:15:47 GMT
References: <481@uncle.UUCP>
Followup-To: poster
Organization: 4455 Province Line Rd., Princeton, NJ 08540
Lines: 26

In article <481@uncle.UUCP>, jbm@uncle.UUCP (John B. Milton) writes:
> 
> Another vote that this is the correct one is the presence of a new section
> two call: LOCKING(2). ...
> ... I also wonder why some UNIX systems call it LOCKF().

Lockf(3C) is a library interface to whatever the underlying system calls
provide for file and record locking.  I believe it is also one of the
ANSI standard, required routines.

Apparently, on the UNIX-PC, the system call is locking(2).  On SVR3, the
fcntl(2) call is used.  The lockf semantics are the same on each system.

On lockf(3C), this routine is documented on the UNIX-PC, appears in
the libc.a archive, but does not seem to be present in the shared
libary ifile.  Is this an oversight like the identifier "daylight"?
I.e., is it really there, but the identifier is not in the list?

The point came up in building netnews software.  I knew lockf(3C) was
there and wanted netnews to use it.  Had to add lines to the makefile
to extract lockf.o from the libc.a archive and link it in where needed.
It would be nice not to have to do this.
-- 
Jon LaBadie
{att, princeton, bcr}!jonlab!jon
{att, attmail, bcr}!auxnj!jon