Disable the BorrowedFd layout optimization on Haiku

[sunfishcode]

On Haiku (and apparently only Haiku), the platform AT_FDCWD has the value -1. However, BorrowedFd currently has layout optimizations that assume the value is not -1, and it's useful to be able to store AT_FDCWD in a BorrowedFd. For example, rustix has
a function which returns a BorrowedFd containing AT_FDCWD.

To support this on Haiku, disable the layout optimizations for BorrowedFd on Haiku and allow it to store the value -1.

This is technically a breaking change for Haiku users, as they could theoretically be depending on Option<BorrowedFd> having the same layout as RawFd, however this is not a common idiom, and Haiku support is Tier 3 in Rust.

[rustbot]

r? @joshtriplett

(rustbot has picked a reviewer for you, use r? to override)

[joshtriplett]

This is technically a breaking change for Haiku users, as they could theoretically be depending on Option<BorrowedFd> having the same layout as RawFd, however this is not a common idiom, and Haiku support is Tier 3 in Rust.

I don't think it's as simple as this. Whatever tier a target is, people are going to ask random crates for support for it, and those crates have to consider whether to support that target or not. And if there is any platform where Option<BorrowedFd> does not work in FFI, that seems like it will more broadly invalidate that usage; anyone using Option<BorrowedFd> in an FFI interface would be unable to ever work on Haiku (or, possibly, even compile at all).

I think we need to make this decision on a broader basis: what do we expect developers in the ecosystem to do?

• Assume this layout optimization, and ignore Haiku?
• Abandon this layout optimization everywhere?
• Use this layout optimization with care and only in non-portable code, and never use it in portable code?

What does Haiku use for "invalid file descriptor"? Are there any Haiku syscalls or library calls where you can pass an optional file descriptor, and there's a (hopefully consistent) placeholder value used to represent not providing a file descriptor?

From what I can tell, Haiku syscalls seem to use large negative numbers as their error values: B_GENERAL_ERROR_BASE is INT_MIN, and then error codes go up from there. But that implies it can return a variety of invalid values, not just one. I don't know if the library functions wrapping those syscalls consistently return a single placeholder value or not.

[sunfishcode]

I don't think it's as simple as this. Whatever tier a target is, people are going to ask random crates for support for it, and those crates have to consider whether to support that target or not. And if there is any platform where Option<BorrowedFd> does not work in FFI, that seems like it will more broadly invalidate that usage; anyone using Option<BorrowedFd> in an FFI interface would be unable to ever work on Haiku (or, possibly, even compile at all).

I think we need to make this decision on a broader basis: what do we expect developers in the ecosystem to do?

In most cases, this layout optimization is just an optimization, so it's not a major problem if some platforms get it and Haiku doesn't.

The one place that does legitimately depend on the layout optimization is FFI declarations. Here, Option<BorrowedFd> is uncommon, and when it does occur, with this PR users will get a "not FFI-safe" warning when compiling for Haiku. They may need to use RawFd instead in those places, which seems like a reasonable outcome.

What does Haiku use for "invalid file descriptor"? Are there any Haiku syscalls or library calls where you can pass an optional file descriptor, and there's a (hopefully consistent) placeholder value used to represent not providing a file descriptor?

Haiku's documentation just says it followed POSIX, so I assume open has to return -1 on failure, otherwise they'd gratuitously break a lot of code.

It happens that the places in POSIX where a -1 fd can meaningfully be passed or returned are disjoint from the places were AT_FDCWD can meaningfully be passed or returned.

[joshtriplett]

r? libs-api

[sunfishcode]

Haiku accepted a patch changing the AT_FDCWD value from -1 to -100, so there's now a path forward that doesn't need this PR.

[sunfishcode]

As of the newly released Haiku R1/beta5, and the Rust libc crate version 0.2.155, the AT_FDCWD value on Haiku is now -100, so now Haiku works like every other platform in this respect.