From owner-freebsd-bugs  Tue May 26 10:45:27 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA13522
          for freebsd-bugs-outgoing; Tue, 26 May 1998 10:45:27 -0700 (PDT)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13514
          for <freebsd-bugs@FreeBSD.org>; Tue, 26 May 1998 10:45:25 -0700 (PDT)
          (envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id KAA11355;
	Tue, 26 May 1998 10:40:01 -0700 (PDT)
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
X-Send-Pr-Version: www-1.0
Subject: misc/6763: ftok(3) should be included in the C library
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         6763
>Category:       misc
>Synopsis:       ftok(3) should be included in the C library
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 26 10:40:01 PDT 1998
>Last-Modified:
>Originator:     Keith Bostic
>Organization:
>Release:        
>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:

>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message