Hello -- I'm wondering whether low-level error handling (specifically POSIX syscall error numbers) is in scope for this group. I'm hoping to get some sort of wrapper-around-u16 defined in either
core or a subcrate of
std so that it's easier to compose libraries when compiling for targets that can't depend on
libc. I started an RFC at https://github.com/rust-lang/rfcs/pull/2973 a few weeks ago but it's not attracted any interest from the libs team, and I don't know who is able to drive something like that forward.
very rough draft at https://github.com/jmillikin/rust-posix-error-numbers (rustdoc)
@John Millikin I remember glancing over this a while ago - I don't think you ever said why you can't depend on libc
I'm using this for targets that don't have libc, either because they're early in the boot process (e.g. a Linux initrd) or because libc is not specified for the platform. I would also like to use this for hacking on systems like Redox which are not based on C.
libc, the C library, is different from
libc the crate
is the crate not available on those platforms?
Many of the comments on that ticket seem to assume that C is the fundamental language of the kernel, which is not true.
It seems pretty bizarre that I would have to depend on another language's standard library, or stub out its build process, to get a standardized newtype for what is essentially an unsigned integer.
libc the crate does not depend on the
libc C library
I feel like we're talking at cross-purposes here: the crate basically is the wrapper around native types that you're asking for
it just has an unfortunate name
libc crate is also a wrapper for the C standard library, in whatever form that takes on the current platform.
If the solution is to move the definition of non-C platform types such as error codes out of libc into its own crate, that seems like a fine solution.
The main benefit of the newtype is that it simplifies comparisons -- I can take a
isize from the kernel, and a
u32 from a spec sheet, and compare them both to the same constant type-safely.
It is 23:30 in my timezone so I'm not going to be able to chat much now, but if there's any way I can help move that proposal along I'd be happy to help. The only thing I really don't want to do is maintain a
posix_error_numbers crate on crates.io, because that seems like an unbounded amount of work to keep such a crate up to date with rustc as people contribute new targets.
@John Millikin absolutely, feel free to create an issue to track this in the project group repo and join the meetings to help drive work on it
I've not given much thought to error codes and I have other tasks that I'd like to drive first personally but I think we can definitely work together to provide feedback on any work you do etc etc
Defining and codifying common error handling terminology. Generating consensus on current error handling best practices. Identifying pain points that exist in Rust’s error handling story. Communicating current error handling best practices. Consolidating the Rust error handling ecosystem.
I think it is definitely within the project group's scope to think about low-level error-handling, even if only because of "identifying pain points". I have also seen people who have concerns about systems that are embedded but want to be able to provide and use the Vec API without panicking in the case of overallocation. (this overlaps with wg-alloc).
Not normally a concern because most people will never allocate anywhere near an isize, nevermind over... but then when you have the entire system resources to yourself because you are the system...
most people will never allocate anywhere near an isize, nevermind over...
remember that on AVR ,
i16 isn't an outrageous number of elements
and note that an allocation size in bytes cannot exceed isize::MAX
I have given more thought to the POSIX types thing myself, having recently seen how mazy that can get as part of e.g. updating the wasm targets, and I do agree that basic bindings to the system that don't _have_ to go through libc probably should not be in that crate. If it's true now that the libc crate can currently be used without depending on the actual libc, then that's Fine But Weird, Frankly, because that doesn't really suggest a promise that such will remain true.
low-level error handling (specifically POSIX syscall error numbers)
My 2¢ is that low-level makes sense for the group, but that POSIX is a combination of "too high" and "too platform specific".
Yeah, I would expect a sensible result to be a little more like "produce a recommendation/guidance/motivation for further approaches to the issue" rather than "do something terribly particular".
Joshua Nelson said:
libcthe crate does not depend on the
This seems to have been communicated to OP already, but perhaps they missed it.
John Millikin said:
I really don't want to do is maintain a
posix_error_numberscrate on crates.io, because that seems like an unbounded amount of work to keep such a crate up to date with rustc as people contribute new targets.
I agree with sfackler's comment in reference to this point.
Thanks! I've filed a tracking issue at https://github.com/rust-lang/project-error-handling/issues/7, and will try to attend meetings if timezones permit.
Might it make sense to pull the error codes into a crate that libc depends on, but that other crates can also depend on? That's the direction that C types might go in the future.
That's the direction that C types might go in the future.
are you talking about
libc or about
libc is working on making cty a dependency which it just publicly re-exports
Last updated: Jan 26 2022 at 14:02 UTC