directory.3: add a STANDARDS section
Details
Details
- Reviewers
jilles ngie - Group Reviewers
manpages - Commits
- rS348466: MFC r347032:
rS347644: MFC r347032 (except for the part about d_off):
rS347032: directory.3: add a STANDARDS section
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Not so fast! I just discovered a serious footgun: Linux's struct dirent has a
d_off field, but it's meaning is different than FreeBSD's. That's worth
mentioning.
Comment Actions
As far as I understand, d_off on FreeBSD is supposed to work the same as on Linux once it is implemented completely. Recent head and stable/12 seems to have most of the kernel part of this (SVN r340431, r340721). However, telldir() and seekdir() in libc still use their old partially broken implementation.
Perhaps we can also mention here that readdir_r()'s API is broken by design since it cannot work if NAME_MAX is not defined as a constant, and http://austingroupbugs.net/view.php?id=696 proposes to deprecate readdir_r() in POSIX and allow readdir() to be thread-safe under some conditions.
| lib/libc/gen/directory.3 | ||
|---|---|---|
| 291 ↗ | (On Diff #56891) | Hmm, why does "should not be used in portable programs" only apply to the fields and not to the function? |
Comment Actions
Interesting. I didn't know that. Is the intent then to change telldir() to return a file offset instead of the weird thing it does now?
Perhaps we can also mention here that readdir_r()'s API is broken by design since it cannot work if NAME_MAX is not defined as a constant, and http://austingroupbugs.net/view.php?id=696 proposes to deprecate readdir_r() in POSIX and allow readdir() to be thread-safe under some conditions.
readdir_r already has a prominent shoutout at the top of the man page.
Comment Actions
As far as I understand, d_off on FreeBSD is supposed to work the same as on Linux once it is implemented completely. Recent head and stable/12 seems to have most of the kernel part of this (SVN r340431, r340721). However, telldir() and seekdir() in libc still use their old partially broken implementation.
Interesting. I didn't know that. Is the intent then to change telldir() to return a file offset instead of the weird thing it does now?
telldir() will still return a cookie, but it will come from d_off rather than the value returned by getdirentries() in *basep with libc magic.
In the case of UFS, d_off contains a file offset but in more modern filesystems it generally contains a cookie that cannot be interpreted by the application.