-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add std::os::set_errno as a counterpart to std::os::errno #17265
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you're at it, the return types of
errno
on unix and windows should be the same, not different. Could you change windows to returning anint
as well? I think that most considererrno
as being a signed integer as opposed to an unsigned one.Additionally,
set_errno
for windows would be updated to take anint
instead of auint
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those should be c_int and not int or uint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, they should not. We do not expose C types at the std layer where
c_int
is a platform-specific definition.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
errno() is mostly (only?!) useful with the values in libc::consts::os::posix88 which are all c_int. If you don't want c_int in the stdlib then maybe the safe version of errno and set_errno should be moved to libc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to expose
errno()
instd
as anint
, but have it be a wrapper around ac_int
-basederrno()
inlibc
, and thenset_errno()
can go intolibc
.The reasoning is that reporting the
errno
in error messages is not an uncommon thing, so having read-only access fromstd
makes sense. Settingerrno
is much rarer, and presumably if you need that you're going to be doing other FFI work as well, so usinglibc
is fine.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thestinger Right; that's exactly what I said.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Rust's
int
type is ever smaller than a C compiler'sint
when compiling for the same target, then either the C compiler is broken, or Rust is. More generally, under that circumstance, I think we'd have more issues than justerrno
.Given that, and since
errno
is not defined to be any specific bit width but instead defined to be the Cint
type, I think it's much more natural to exposeerrno
fromstd
asint
instead of trying to claim it's some particular bit width. Yes, it's not a perfect match, but it seems like a better choice thani32
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that my above comment is predicated on
std
only exposingerrno
as a read-only value, andlibc
exposingerrno
as a read/write value usingc_int
, as stated in my previous comment.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A C compiler with a 32-bit
int
type and 16-bit pointers is not "broken". The same applies to one with a 64-bitint
type and 32-bit pointers. If a compiler tiedint
to general purpose register size, it would be 64-bit on x32 while pointers (and thusint
anduint
in Rust) are 32-bit.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcrichton
You're already doing this by re-exporting CString which takes c_char.