Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000786 [1003.1(2008)/Issue 7] System Interfaces Editorial Enhancement Request 2013-11-04 21:57 2015-09-11 15:47
Reporter joerg View Status public  
Assigned To ajosey
Priority normal Resolution Future Enhancement  
Status Under Review  
Name Jörg Schilling
Organization FOKUS Fraunhofer
User Reference
Section 3 System Interfaces
Page Number 893
Line Number 29895-29905
Interp Status ---
Final Accepted Text
Summary 0000786: pathconfat() is missing
Description We need a universal system for path name based interfaces.
As we have openat(), we also need pathconfat().
Desired Action after line 29900 add:

lonf pathconfat(int fd, const char *oath, int name);

after line 29905 add:

The pathconfat() function shall be equivalent to the pathconf() function except in the case where path specifies a relative path. In this case the file to be checked is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the file descriptor was opened without O_SEARCH, the function shall check whether directory searches are permitted using the current permissions of the directory underlying the file descriptor. If the file descriptor was opened with O_SEARCH, the function shall not perform the check.

If pathconfat() is passed the special value AT_FDCWD in the fd parameter, the current working directory shall be used and the behavior shall be identical to a call to pathconf().

If pathconfat() is passed a NULL pointer for path, pathfonfat() acts like fpathconf().
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0001957)
eblake (manager)
2013-11-04 22:12

 Is there existing practice? If not, then I highly suggest adding an 'int flags' parameter. One of the real powers of openat(), but where mkdirat() falls short, is the extensibility offered by having a flags parameter as part of the interface. Also, none of the existing *at() functions mandate behavior for a NULL path, instead choosing to leave this for implementation extensions; I see no reason why we should operate any differently for pathconfat().
(0001958)
shware_systems (reporter)
2013-11-05 08:34
edited on: 2013-11-05 08:35

 I think this is a duplicate request from Issue 6. The consensus then IIRC was as fpathconf() was provided the application could use open() or openat() to get a fd for use with that to block race conditions, which is possible while a call to pathconf(), and other interfaces with at() variants, is in progress. The corner case where this interface would be needed, when OPEN_MAX descriptors were already in use by the application, was considered insufficient reason to add this to Issue 7. I thought it was sufficient but was outvoted. That's my recollection. So now there's two votes for it :-)

I agree with adding the flags parameter, to support AT_SYMLINK_NOFOLLOW as some other *at() interfaces do. I could see that flag being a sysconf() system option addition or session global shell option, actually, but that's a separate issue. Current practice is some interfaces that deal with paths are allowed to have it as a per-call option and it wouldn't hurt with this one.

Also, I read mkdir() and mkdirat() as they 'shall fail' with ENOENT when the path argument is NULL, as there's no language overriding C's default of NULL char * dereferences being treated as char * to '/0' and it never resolves to a valid path, according to XBD 4.12. Most other interfaces I checked that have a char *path argument have this error case as 'shall fail' too. This implication may be considered non-binding in some respects (glibc returns EINVAL instead for mkdirat() ), and it's a 'may fail' for pathconf(), but it seems to be the intent. The only extension I could think of offhand that might be of use is for an interface that fills in a structure with path specific data, like fstatat(), using a NULL argument as a command to fill it with non-zero default data. For this I think the proposed behavior for NULL to override the 'may fail' case is reasonable enough.
(0001966)
joerg (reporter)
2013-11-07 14:16

 I have no problems with adding a flag argument to the function,
there is no existing code yet.

I stepped over the problem recently while enhancing star to
support NFSv4 ACLs and thinking about adding support for arbitrary
long path names in the future. When I am going to do this, I would
need pathconfat() as it needs to be called before/without calling
open() in many cases. For this reason, fpathconf would not work
here.

BTW: the *at() group of interfaces was first introduced in
Summer 2001 on Solaris and Solaris implements the NULL pointer
behavior in question with related *at() interfaces.
(0001967)
dalias (reporter)
2013-11-07 16:30

 Could the author of note 0001958 clarify the text: "as there's no language overriding C's default of NULL char * dereferences being treated as char * to '/0' and it never resolves to a valid path"? As written it makes no sense, and I have not been able to make any interpretation of it that agrees with anything in the C or POSIX standards.
(0002086)
eblake (manager)
2013-12-19 16:57
edited on: 2013-12-19 17:02

 This was discussed on the 19 Dec 2013 teleconference; while there is consensus that the interface would be useful to have, we are reluctant to standardize it without first having interface practice. For now, we will leave the issue open, with the intent to revisit it later when there is an existing implementation.

Note that the interface proposed in the Desired Action may be insufficient; the need for a flags argument should be investigated, as well as consideration for any interface named fpathconfat(). Also note that FreeBSD has lpathconf(), which may be a subset of the functionality proposed for pathconfat().
(0002095)
shware_systems (reporter)
2014-01-08 14:23

 Re: 1967

You are correct it is not part of the standard, per se, so I was probably thinking of a particular implementation that defined that behavior where the standard leaves it undefined in Section 7.1.4, #1. Sorry for the confusion, but I did think it was in there at the time. As I've used or tried out a lot of different versions of C by various vendors in over 30 years things do blur together sometimes, so can't say for certain which version that may have been.

As many of the str* interfaces in POSIX also don't define error codes for an argument being NULL that convention is at least reasonable for source arguments and some destination ones too, so the function provides consistent results, and avoids memory access faults by not trying to read or write location 0.
(0002827)
geoffclare (manager)
2015-09-11 15:47

 If we don't add pathconfat(), with a flags argument, then we should add FreeBSD's lpathconf(). Reason is that the standard currently lacks any way to query the timestamp resolution of a symlink. In practice it is probably reasonably safe to use the timestamp resolution of the directory containing the symlink, but the standard does not require them to be the same.

- Issue History
Date Modified Username Field Change
2013-11-04 21:57 joerg New Issue
2013-11-04 21:57 joerg Status New => Under Review
2013-11-04 21:57 joerg Assigned To => ajosey
2013-11-04 21:57 joerg Name => Jörg Schilling
2013-11-04 21:57 joerg Organization => FOKUS Fraunhofer
2013-11-04 21:57 joerg Section => 3 System Interfaces
2013-11-04 21:57 joerg Page Number => 893
2013-11-04 21:57 joerg Line Number => 29895-29905
2013-11-04 22:12 eblake Note Added: 0001957
2013-11-05 08:34 shware_systems Note Added: 0001958
2013-11-05 08:35 shware_systems Note Edited: 0001958
2013-11-07 14:16 joerg Note Added: 0001966
2013-11-07 16:30 dalias Note Added: 0001967
2013-12-19 16:57 eblake Interp Status => ---
2013-12-19 16:57 eblake Note Added: 0002086
2013-12-19 16:57 eblake Resolution Open => Future Enhancement
2013-12-19 17:02 eblake Note Edited: 0002086
2014-01-08 14:23 shware_systems Note Added: 0002095
2015-09-11 15:47 geoffclare Note Added: 0002827

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