perlfunc/stat: fix description of S_ENFMT and S_IFMT #22203
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
S_ENFMT properly belongs to the group of permission bits (like setuid/setgid), not file types. On systems that have it (like AIX), it can be set/cleared with chmod(). (In fact, it usually shares its value with S_ISGID because enforced locking is signaled by the combination of a non-executable file with the setgid bit set.) S_IFMT($mode) directly gives you one of the file types (S_IFREG, S_IFDIR, etc). You don't need to bit-and it further (especially not with the S_IS* functions), contrary to what the comment claims. (The confusion likely stems from the C side of things, where you'd do `mode & S_IFMT` to extract the file type from the mode bits, leading to code like `(mode & S_IFMT) == S_IFDIR`. But even then you could write `S_ISDIR(mode)` without any bit mask trickery.) Most of the symbols in the "S_IF* constants" section don't start with "S_IF", so change to "S_I* constants" everywhere. Most of the symbols in the "S_IF* functions" section don't start with "S_IF" (with the sole exception of S_IFMT, which is only a function in Perl; the C macro is a constant). (Historical note: This section label used to make more sense because it documented S_IFMODE and S_IFMT functions, but the former was just a typo for S_IMODE.)
|
Makes sense & LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
S_ENFMT properly belongs to the group of permission bits (like setuid/setgid), not file types. On systems that have it (like AIX), it can be set/cleared with chmod(). (In fact, it usually shares its value with S_ISGID because enforced locking is signaled by the combination of a non-executable file with the setgid bit set.)
S_IFMT($mode) directly gives you one of the file types (S_IFREG, S_IFDIR, etc). You don't need to bit-and it further (especially not with the S_IS* functions), contrary to what the comment claims. (The confusion likely stems from the C side of things, where you'd do
mode & S_IFMTto extract the file type from the mode bits, leading to code like(mode & S_IFMT) == S_IFDIR. But even then you could writeS_ISDIR(mode)without any bit mask trickery.)Most of the symbols in the "S_IF* constants" section don't start with "S_IF", so change to "S_I* constants" everywhere.
Most of the symbols in the "S_IF* functions" section don't start with "S_IF" (with the sole exception of S_IFMT, which is only a function in Perl; the C macro is a constant).
(Historical note: This section label used to make more sense because it documented S_IFMODE and S_IFMT functions, but the former was just a typo for S_IMODE.)