Skip to content

[fs.class.path.general] Defuse cross-reference to POSIX #7025

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 9, 2024

Conversation

jensmaurer
Copy link
Member

Fixes ISO/CS comment (C++23 proof)

  • where is section 4.12? Is this in the POSIX document? If so, please be more specific i.e. "The pathname resolution mechanism is described in POSIX, section 4.12."

@jensmaurer jensmaurer added the ballot-comment Response to an NB or ISO comment on a ballot label May 16, 2024
@jensmaurer jensmaurer added this to the C++23 milestone May 16, 2024
\begin{example}
POSIX specifies the mechanism in section 4.12, Pathname resolution.
\end{example}
a pathname to a particular file in a file hierarchy (see POSIX, section 4.12).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to suggest that POSIX defines the mechanism, but that's only true for POSIX-based operating systems. i.e., this seems to contradict the first half of the sentence.

Suggested change
a pathname to a particular file in a file hierarchy (see POSIX, section 4.12).
a pathname to a particular file in a file hierarchy.
\begin{example}
For POSIX-based operating systems, this mechanism is specified in POSIX section 4.12).
\end{example}

I'm a little sad to lose the "Pathname Resolution" part, because while "POSIX 4.12" unambiguously means "ISO/IEC/IEEE 9945:2009 4.12" in this document, when POSIX 2024 gets published in the near future the correct section will be different (it's 4.16 in the current 202x draft 4 doc). If we also name the section then somebody consulting the latest POSIX spec will be able to find it more easily, without having to check what 4.12 in older spec corresponds to. I realise that checking the older spec is more correct, since that's our normative reference. But people often want to consult the latest spec, since that might be what their implementation's libc actually conforms to.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is less of a change. Applied.

@tkoeppe tkoeppe merged commit 5383169 into cplusplus:main Jul 9, 2024
2 checks passed
@jensmaurer jensmaurer deleted the e28 branch July 28, 2024 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ballot-comment Response to an NB or ISO comment on a ballot
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants