Stream: project-error-handling

Topic: Is low-level OS error handling in scope for this group?


view this post on Zulip John Millikin (Sep 19 2020 at 14:22):

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.

view this post on Zulip John Millikin (Sep 19 2020 at 14:24):

very rough draft at https://github.com/jmillikin/rust-posix-error-numbers (rustdoc)

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:24):

@John Millikin I remember glancing over this a while ago - I don't think you ever said why you can't depend on libc

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:25):

https://github.com/rust-lang/rfcs/pull/2973#issuecomment-671108502

view this post on Zulip John Millikin (Sep 19 2020 at 14:26):

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.

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:26):

libc, the C library, is different from libc the crate

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:26):

is the crate not available on those platforms?

view this post on Zulip John Millikin (Sep 19 2020 at 14:26):

Many of the comments on that ticket seem to assume that C is the fundamental language of the kernel, which is not true.

view this post on Zulip John Millikin (Sep 19 2020 at 14:28):

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.

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:28):

libc the crate does not depend on the libc C library

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:29):

I feel like we're talking at cross-purposes here: the crate basically is the wrapper around native types that you're asking for

view this post on Zulip Joshua Nelson (Sep 19 2020 at 14:29):

it just has an unfortunate name

view this post on Zulip John Millikin (Sep 19 2020 at 14:29):

The libc crate is also a wrapper for the C standard library, in whatever form that takes on the current platform.

view this post on Zulip John Millikin (Sep 19 2020 at 14:30):

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.

view this post on Zulip John Millikin (Sep 19 2020 at 14:31):

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.

view this post on Zulip John Millikin (Sep 19 2020 at 14:33):

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.

view this post on Zulip Jane Lusby (Sep 19 2020 at 20:33):

@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

view this post on Zulip Jane Lusby (Sep 19 2020 at 20:33):

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

view this post on Zulip Jubilee (Sep 20 2020 at 00:25):

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...

view this post on Zulip Jake Goulding (Sep 20 2020 at 00:27):

Jubilee said:

most people will never allocate anywhere near an isize, nevermind over...

remember that on AVR , usize == u16, so i16 isn't an outrageous number of elements

view this post on Zulip Lokathor (Sep 20 2020 at 00:34):

and note that an allocation size in bytes cannot exceed isize::MAX

view this post on Zulip Jubilee (Sep 20 2020 at 00:39):

Yeaaaah.

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.

view this post on Zulip Jake Goulding (Sep 20 2020 at 00:42):

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".

view this post on Zulip Jubilee (Sep 20 2020 at 00:48):

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".

view this post on Zulip Jake Goulding (Sep 20 2020 at 00:48):

Joshua Nelson said:

libc the crate does not depend on the libc C library

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_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.

I agree with sfackler's comment in reference to this point.

view this post on Zulip John Millikin (Sep 20 2020 at 01:34):

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.

view this post on Zulip Lokathor (Sep 20 2020 at 06:05):

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.

view this post on Zulip Joshua Nelson (Sep 20 2020 at 12:49):

That's the direction that C types might go in the future.

are you talking about libc or about target_lexicon?

view this post on Zulip Lokathor (Sep 20 2020 at 14:46):

libc is working on making cty a dependency which it just publicly re-exports


Last updated: Jan 26 2022 at 14:02 UTC