From nobody  Tue May 26 10:41:48 1998
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA12908;
          Tue, 26 May 1998 10:41:48 -0700 (PDT)
          (envelope-from nobody)
Message-Id: <199805261741.KAA12908@hub.freebsd.org>
Date: Tue, 26 May 1998 10:41:48 -0700 (PDT)
From: bostic@bostic.com
To: freebsd-gnats-submit@freebsd.org
Subject: ftok(3) should be included in the C library
X-Send-Pr-Version: www-1.0

>Number:         6763
>Category:       misc
>Synopsis:       ftok(3) should be included in the C library
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jdp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 26 10:40:01 PDT 1998
>Closed-Date:    Wed Jun 10 09:21:50 PDT 1998
>Last-Modified:  Wed Jun 10 09:24:52 PDT 1998
>Originator:     Keith Bostic
>Release:        
>Organization:
>Environment:
>Description:
I'm seeing reports from FreeBSD machines that Berkeley DB doesn't
correctly build.

The problem is that ftok(3) is in libcompat.a.  The DB autoconf
scripts check for shmget(2), but they don't check for both ftok 
and shmget.

The obvious workaround, that I've already implemented, is to not
use shmget(2) unless ftok(3) is also found.

However, ftok(3) should be in the C library.

1: Shared memory backed by memory/swap space instead of the file system
   is a performance advantage for large server applications under UNIX,  
   and if more than one process is using the memory, it has to be named.
   SysV shared memory is the only portable way to created these regions 
   under UNIX.

2: Ftok(3) is the only portable way to generate keys for shmget(2) (key 
   naming in shmget(2) is so irretrievably stupid that you have to rely 
   on the operating system to know what is "unique" in the filesystem name 
   space).  

3. Every vendor of which I'm aware puts ftok(3) in the C library --
   my autoconfigure scripts test for shmget(2) because it might not
   be available, but it never even occurred to me to further test for
   ftok(3).

If you're going to offer System V shared memory, ftok(3) should be
in the C library.

--keith

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Wed May 27 02:26:28 PDT 1998 
State-Changed-Why:  
This takes a cvs-meister... 


Responsible-Changed-From-To: freebsd-bugs->cvs 
Responsible-Changed-By: phk 
Responsible-Changed-When: Wed May 27 02:26:28 PDT 1998 
Responsible-Changed-Why:  
. 
State-Changed-From-To: suspended->analyzed 
State-Changed-By: jdp 
State-Changed-When: Tue Jun 9 13:24:15 PDT 1998 
State-Changed-Why:  
I will do the necessary repository copy and fix this within the next 
week or so. 


Responsible-Changed-From-To: cvs->jdp 
Responsible-Changed-By: jdp 
Responsible-Changed-When: Tue Jun 9 13:24:15 PDT 1998 
Responsible-Changed-Why:  
State-Changed-From-To: analyzed->closed 
State-Changed-By: jdp 
State-Changed-When: Wed Jun 10 09:21:50 PDT 1998 
State-Changed-Why:  
Fixed in: 
1.46      +3 -3      src/lib/libc/gen/Makefile.inc 
1.16      +1 -8      src/lib/libcompat/Makefile 
and the simultaneous removal of lib/libcompat/SysV/ftok.{3,c}. 

I will merge this change into the -2.2 branch in a couple of weeks if it 
doesn't cause problems in -current. 
>Unformatted:
