--- Begin Message ---
- To: austin-group-l@xxxxxxxxxxxxx
- Subject: Proposed submissions for the revision from The Open Group
- From: Andrew Josey <ajosey@xxxxxxxxxxxxxxxxx>
- Date: Mon, 9 Jan 2006 18:47:58 GMT
- Resent-date: 9 Jan 2006 18:49:00 -0000
- Resent-from: austin-group-l@xxxxxxxxxxxxx
- Resent-message-id: <CilEgC.A.A0B.v_qwDB@mailman>
- Resent-sender: austin-group-l-request@xxxxxxxxxxxxx
- Resent-to: austin-group-l@xxxxxxxxxxxxx
All
This is a note to record the proposed submissions for
the revision project from The Open Group.
The Open Group Base Working Group is considering submitting
a number of API sets for the revision. These are currently undergoing
development as Technical Standards and are expected to complete in time
to meet the July 31 Austin Group Revision milestone.
The purpose of these Technical Standards is to define sets of New API
Extensions to further increase application capture and hence portability
for systems built upon version 3 of the Single UNIX Specification .
API Set 1:
The scope of this set of extensions has been to consider interfaces
drawn from existing open source implementations such as the GNU C library.
The Extended API Set Part 1 is expected to consist of twenty-five
new system interfaces, and one extension to the ls utility. It also
introduces the concept of a stream associated with a memory buffer
to eliminate may of the errors encountered in the construction
of strings, notably overflowing of strings.
The system interfaces are as follows (listed by header):
<dirent.h>
alphasort()
dirfd()
scandir()
<signal.h>
psignal()
psiginfo()
<stdio.h>
dprintf()
fmemopen()
getdelim()
getline()
open_memstream()
open_wmemstream()
<stdlib.h>
mkdtemp()
<string.h>
stpcpy()
stpncpy()
strndup()
strnlen()
strsignal()
<wchar.h>
mbsnrtowcs()
wcpcpy()
wcpncpy()
wcscasecmp()
wcsdup()
wcsncasecmp()
wcsnlen()
wcsnrtombs()
API Set 2:
The motivation for the introduction of this set of interfaces is as
follows:
* Interfaces taking a path name are limited by the maximum length of
a path name(_SC_PATH_MAX). The absolute path of files can far exceed
this length. The current solution would be to change the working
directory and use relative path names. This is not thread-safe.
* A second motivation is that files accessed outside the current
working directory are subject to attacks caused by the race condition
created by change any of the elements ofthe path names used.
* A third motivation is to allow implementing code which uses a
virtual current working directory for each individual thread. In
the current model there is only one current working directory for
all threads.
The new interfaces solve these issues by duplicating existing interfaces
using path names with one change, that is an additional parameter. This
additional parameter must be a file descriptor for a directory. The
operations will then work relative to the specified directory instead
of the current working directory whenever the later would be accessed.
The set of interfaces includes:
faccessat()
fchmodat()
fchownat()
fdopendir()
fexecve()
fstatat()
futimesat()
linkat()
mkdirat()
mkfifoat()
mknodat()
openat()
readlinkat()
renameat()
symlinkat()
unlinkat()
It is also possible that additional API sets addressing Robust Mutexes and
Thread Locale extensions may also be brought forward. Further information
will be presented at the February meeting.
regards
Andrew
-----
Andrew Josey The Open Group
Director, Server Platforms Thames Tower, 37-45 Station Road
Email: a.josey@xxxxxxxxxxxxx Reading,Berks.RG1 1LX,England
Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
Mobile: +44 774 015 5794
UNIX is a registered trademark of The Open Group in the US
and other countries.
--- End Message ---
