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. |
|