Skip to content
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

Unix ExitStatus comments and a tiny docs fix #90704

Merged
merged 3 commits into from
Nov 12, 2021

Conversation

ijackson
Copy link
Contributor

@ijackson ijackson commented Nov 8, 2021

Some nits left over from #88300

@rust-highfive
Copy link
Collaborator

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 8, 2021
Comment on lines 1421 to 1426
// We speak slightly loosely (here and in various other places in the stdlib docs) about `exit`
// rather than `_exit`. Strictly speaking, an exit status is a value passed to the `_exit` system
// call, around which `exit` is a library wrapper. But anyone who knows the difference will not be
// misled; anyone who does not, does not want to be distracted by some subtle point of UNIX APIs.
// (Also, the distinction between syscalls and library functions is not standardised, although Unix
// people typically have common notions.)
Copy link
Member

@joshtriplett joshtriplett Nov 11, 2021

Choose a reason for hiding this comment

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

This comes across to me very much like "UNIX people understand this and other people don't need to" elitism. I'm not suggesting that that's the intent, but I feel like it's the net effect.

I also don't think it's necessary for the purposes of conveying this point. As far as I can tell, libc::exit and libc::_exit and the Linux syscall exit and return from main all accept an exit status value, and pass it along. So the point worth conveying here seems more like this:

Suggested change
// We speak slightly loosely (here and in various other places in the stdlib docs) about `exit`
// rather than `_exit`. Strictly speaking, an exit status is a value passed to the `_exit` system
// call, around which `exit` is a library wrapper. But anyone who knows the difference will not be
// misled; anyone who does not, does not want to be distracted by some subtle point of UNIX APIs.
// (Also, the distinction between syscalls and library functions is not standardised, although Unix
// people typically have common notions.)
// When this documentation refers to a status passed to `exit` or similar, this
// loosely refers to any mechanism that exits a process and accepts an exit
// code, including system calls, library calls that make such system calls, or
// returning from a program's main function to a library that invokes such
// system calls.

(modulo word-wrapping)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think you have missed something: This isn't a doc comment. I agree that this kind of language would be inappropriate in public docs.

The audience is other people who are editing this code or its documentation. The purpose is to explain to any passing Unix pedants why the docs are the way they are.

Copy link
Member

Choose a reason for hiding this comment

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

I didn't think it was a doc comment. It's still documentation, just with an audience of people who read the code. We're friendly to each other, too, not just to users.

That said, I do understand the desire to quell pedantry, UNIXy or otherwise. But I think if we want to avoid attracting or encouraging that kind of UNIX pedantry, it'll also help to avoid playing into divisions based on who has which bits of UNIX ingroup knowledge.

@apiraino apiraino added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Nov 11, 2021
As discussed here
 rust-lang#88300 (comment)

exit is (conventionally) a library function, with _exit being the
actual system call.

I have checked the other references and they say "if the process
terminated by calling `exti`".  I think despite the slight
imprecision (strictly, it should read iff ... `_exit`), this is
clearer.  Anyone who knows about the distinction between `exit` and
`_exit` will not be confused.

`_exit` is the correct traditional name for the system call, despite
Linux calling it `exit_group` or `exit`:
  https://www.freebsd.org/cgi/man.cgi?query=_exit&sektion=2&n=1

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
With cross-reference.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
As discussed here
 rust-lang#88300 (comment)

I felt this was the best place to put this (rather than next to
ExitStatusExt).  After all, it's a property of the ExitStatus type on
Unix.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
@ijackson ijackson force-pushed the exitstatus-comments branch from 0863e33 to fe39fb3 Compare November 11, 2021 17:50
@ijackson
Copy link
Contributor Author

I have (force pushed and) updated the wording. I hope this now doesn't read as patronising.

@joshtriplett
Copy link
Member

@bors r+

Thank you for the documentation, and for the adaptations as well.

@bors
Copy link
Contributor

bors commented Nov 12, 2021

📌 Commit fe39fb3 has been approved by joshtriplett

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 12, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 12, 2021
…askrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#90589 (rustc_llvm: update PassWrapper for recent LLVM)
 - rust-lang#90644 (Extend the const swap feature)
 - rust-lang#90704 (Unix ExitStatus comments and a tiny docs fix)
 - rust-lang#90761 (Shorten Span of unused macro lints)
 - rust-lang#90795 (Add more comments to explain the code to generate the search index)
 - rust-lang#90798 (Document `unreachable!` custom panic message)
 - rust-lang#90826 (rustc_feature: Convert `BuiltinAttribute` from tuple to a struct)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 160602b into rust-lang:master Nov 12, 2021
@rustbot rustbot added this to the 1.58.0 milestone Nov 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants