Austin Group Defect Tracker

Aardvark Mark III

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000366 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2010-12-29 02:51 2013-04-16 13:06
Reporter weeks View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Nathan Weeks
Organization Iowa State University HPC Group
User Reference
Section ftok
Page Number 958
Line Number 32805
Interp Status Approved
Final Accepted Text See Note: 0000660
Summary 0000366: ftok() with paths on the same filesystem
Description The ftok() description contains the text:

    The ftok() function shall ... return different key values when called with
    different id values or with paths that name different files existing on the
    same file system at the same time.

At least the Solaris 10u9 and AIX 7.1 manual pages imply that different paths
inthe same filesystem may result in the same key value.

Also, the sentences describing the ftok() examples begin with "The following
example gets a unique key...".
Desired Action Reword these parts if necessary.
Tags tc1-2008
Attached Files

- Relationships
related to 0000343Closedajosey ftok cleanups 

-  Notes
msbrown (manager)
2011-01-20 17:53

Just so the information will not be lost while considering the ways to resolve this:

CDE [ [^] ] created a set of routines for creating unique identifiers (UUID) for use in interprocess communication, that may lead us to some answers for this problem. I know AIX and HP picked these up.
nick (manager)
2011-01-27 17:17

For TC1, proposed change is:

On line 32809 change "and return different key values when called with different id ..."


"and should return different key values when called with different id ..."

Add to Application Usage:
No guarantee can be given that the resulting key value is unique.

In Examples, on line 32119 and 32129 delete the word "unique".

In Future Directions change "None" to

"Future versions of this standard may add new interfaces to provide guaranteed unique keys."
nick (manager)
2011-01-27 17:19
edited on: 2011-01-27 17:20

Interpretation response
The standard states that the key shall be unique, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

See notes above. No current implementation is known to provide unique keys.

Notes to the Editor (not part of this interpretation):
See Note: 0000659

drepper (reporter)
2011-01-27 17:42

I think it is problematic that the interpretation even hints at a new interface to help solve the issue.

The fundamental problem is that the key_t type is usually severely limited. Many implementations only use 16 bits. Not much uniqueness to achieve.

Just as for IP ports (see the IETF proposals), the only way to get some uniqueness is to use strings. This we already have in the POSIX shm, msg, sem interfaces. If people are missing functionality in those interfaces, that's what would have to be worked on. Let the key_t-using interfaces die. Otherwise you'd have to implement a whole new set of interfaces and this will only create compatibility issues.
ajosey (manager)
2011-03-15 14:46

Interpretation proposed 15 Mar 2011 for final 30 day review
ajosey (manager)
2011-04-26 15:11

The interpretation is now approved.

- Issue History
Date Modified Username Field Change
2010-12-29 02:51 weeks New Issue
2010-12-29 02:51 weeks Status New => Under Review
2010-12-29 02:51 weeks Assigned To => ajosey
2010-12-29 02:51 weeks Name => Nathan Weeks
2010-12-29 02:51 weeks Organization => Iowa State University HPC Group
2010-12-29 02:51 weeks Section => ftok
2010-12-29 02:51 weeks Page Number => 0
2010-12-29 02:51 weeks Line Number => 0
2010-12-29 02:52 weeks Issue Monitored: weeks
2011-01-20 17:53 msbrown Note Added: 0000654
2011-01-27 17:07 nick Page Number 0 => 958
2011-01-27 17:07 nick Line Number 0 => 32805
2011-01-27 17:07 nick Interp Status => ---
2011-01-27 17:17 nick Note Added: 0000659
2011-01-27 17:19 nick Interp Status --- => Pending
2011-01-27 17:19 nick Note Added: 0000660
2011-01-27 17:19 nick Status Under Review => Interpretation Required
2011-01-27 17:19 nick Resolution Open => Accepted As Marked
2011-01-27 17:20 nick Final Accepted Text => See Note: 0000660
2011-01-27 17:20 nick Note Edited: 0000660
2011-01-27 17:22 nick Tag Attached: tc1-2008
2011-01-27 17:42 drepper Note Added: 0000662
2011-03-15 14:46 ajosey Interp Status Pending => Proposed
2011-03-15 14:46 ajosey Note Added: 0000704
2011-04-22 10:44 eblake Relationship added related to 0000343
2011-04-26 15:11 ajosey Interp Status Proposed => Approved
2011-04-26 15:11 ajosey Note Added: 0000767
2013-04-16 13:06 ajosey Status Interpretation Required => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker