Those are FreeBSD-specific member and flags still better to be documented.
Follow-up to the https://reviews.freebsd.org/D59910
Details
Details
- Reviewers
kib - Group Reviewers
manpages - Commits
- rG72e391060bb6: stat(2): Document st_bsdflags and SFBSD_NAMEDATTR
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| lib/libsys/stat.2 | ||
|---|---|---|
| 176 | We already have system flags, subset of the flags reported in st_flags. Using the 'system' adjective there would be confusing. Imo replacing s/system/file/ or removing the word would be enough. | |
| 366 | It does not make sense to repeat the style of st_mode there. st_mode is special in that all systems use the same bits positions for the Unix DACs and type. But st_bsdflags are just normal FreeBSD-specific flags. It should be enumerated as the usual display list, with the description. Good example is the open(2) O_ flags. | |
| 499 | If the field is not portable, then all flags provided there are also not portable. There is no need to repeat the flags list. | |
| lib/libsys/stat.2 | ||
|---|---|---|
| 499 |
Well, I'd argue that even a non-portable field can take some publicly accessible portable flags defined in a different domain, or flag could be for example moved from non-portable to portable and (rarely) back via the standardization and planned obsolesce processes. But OK. | |