fix compilation on uefi (with std feature enabled) or i686

[usamoi]

According to https://uefi.org/specs/UEFI/2.10/Apx_D_Status_Codes.html, there is no more space for internal errors, so use a wider integer on UEFI.

[newpavlov]

I don't understand why we need the Error changes. The UEFI status codes are not relevant for the RDRAND backend.

Also please add a build-only CI job for this target, see here.

[usamoi]

@newpavlov If we use std on uefi targets, code does not compile since RawOsError on uefi is usize: https://github.com/rust-lang/rust/blob/37e74596c0b59e81b9ac58657f92297ef4ccb7ef/library/std/src/sys/pal/uefi/mod.rs#L36

[newpavlov]

But we do not use RawOsError anywhere. Yes, on UEFI it's not i32 which we return from raw_os_error, but this method will always return None on UEFI targets with the existing backends. Even with a custom backend you will not be able to craft an Error from an UEFI code.

[newpavlov]

Could you please split the Error changes into a separate PR? I can merge the other changes right away.

[usamoi]

But we do not use RawOsError anywhere. Yes, on UEFI it's not i32 which we return from raw_os_error, but this method will always return None on UEFI targets with the existing backends. Even with a custom backend you will not be able to craft an Error from an UEFI code.

Ok. I'll remove code about Error.

[newpavlov]

It may be worth to reconsider our use of NonZeroU32 for error codes. IIRC previously we had a similar issue with Windows UWP backend which was using the higher bits similarly to the UEFI codes. And in future we may add a proper UEFI backend on top of EFI_RNG_PROTOCOL.

But it's unclear how it's better to do this. I don't think we should just double the Error size.

[newpavlov]

Thank you!