Page MenuHomeFreeBSD

directory.3: add a STANDARDS section
ClosedPublic

Authored by asomers on Apr 30 2019, 6:09 PM.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 24052
Build 22935: arc lint + arc unit

Event Timeline

asomers created this revision.Apr 30 2019, 6:09 PM
This revision is now accepted and ready to land.Apr 30 2019, 6:31 PM
asomers updated this revision to Diff 56891.Apr 30 2019, 10:28 PM

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.

This revision now requires review to proceed.Apr 30 2019, 10:28 PM

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.

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

Hmm, why does "should not be used in portable programs" only apply to the fields and not to the function?

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.

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?

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.

asomers updated this revision to Diff 56939.May 1 2019, 11:56 PM
asomers marked an inline comment as done.

Address jilles' feedback

jilles accepted this revision.May 2 2019, 7:51 PM

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.

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.

This revision is now accepted and ready to land.May 2 2019, 7:51 PM
This revision was automatically updated to reflect the committed changes.