Breaking change in v0.2.145 for MUSL's open64

[newpavlov]

Previously, open64 on MUSL was using the common definition with variadics. But in v0.2.145 it was migrated to a non-variadic definition. This has caused breakage of getrandom v0.1, see rust-random/getrandom#363.

cc @bossmc

[bossmc]

Good spot, and yes indeed that's an unintended change - the whole point of that module is to back-fill a non-breaking API. Unfortunately, we can't shim variadic functions since they're unstable (as local functions) rust-lang/rust#44930. If that were merged we could write something like:

pub unsafe extern "C" fn open64(
    pathname: *const ::c_char,
    flags: ::c_int,
    mode: ...,
) -> ::c_int {
    ::open(pathname, flags, mode)
}

An earlier version of this change re-exported the LFS64 symbols with use foo as foo64 which caused two problems:

1. The aliased symbols are the original symbols (have the same address for example) which would be a breaking change
2. use will alias all matching symbols (which is a problem for e.g. stat64 which is a type and a function)

The latter of these doesn't matter for open/openat since there's no type to conflict with the function name, but the former would still be a concern.

@JohnTitor @Amanieu - I proposed for now we switch open/openat to be aliased with a use (with a comment to re-visit once c_variadics is stabilized. thoughts?

[bossmc]

Oh, there's a 3rd problem with use-aliasing that also doesn't affect open/openat - if the arguments of an LFS64 function are themselves LFS64-ized then a use-aliased function won't accept them when it should. Doesn't change my previous conclusion, just providing completeness.

[Amanieu]

I agree with changing this to a use, I think this is the best way forward.

[Amanieu]

I've yanked v0.2.145 for now since it is causing widespread breakage.

[newpavlov]

I think this issue can be closed now?