[libcxx-commits] [PATCH] D116045: [libc++] Use arc4random instead of /dev/urandom on Apple platforms
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Dec 21 08:22:50 PST 2021
ldionne added a comment.
Turns out this is an ABI break:
1. `random_device` contains this, so we'd be changing the layout of the type:
class random_device {
#ifdef _LIBCPP_USING_DEV_RANDOM
int __f_;
#endif
....
};
2. When using `arc4random`, `std::random_device`'s constructor will throw whenever the token isn't exactly `"/dev/urandom"`. Previously, it would work with any token that represents a path that we can `std::open()`.
If we're willing to break (2), then I think there's definitely a way we can still roll this out by retaining the same field in the struct.
Are we willing to break (2)? Well, http://eel.is/c++draft/rand.device#lib:random_device,constructor says:
> Throws: A value of an implementation-defined type derived from exception if the `random_device` cannot be initialized.
> Remarks: The semantics of the `token` parameter and the token value used by the default constructor are implementation-defined.
So technically, users should not be expecting a whole lot of portability if they are using these custom tokens. In practice, I suspect users don't really provide a custom token cause we've never documented our "implementation-defined" behavior, but I could be wrong.
For the above reasons, and considering the benefits of using `arc4random`, I would be willing to give a shot at this. The strategy would basically be to keep the `int __f_` around to preserve the layout of `std::random_device`, but not do anything with it. Since all the class methods are defined in the dylib, any old code compiled against the previous definition of `std::random_device` will still work when run against the new dylib, but it won't use the `int __f_` in the struct. Any code compiled against the new library (headers + dylib) but running against an older dylib will also work, since it will still have the `int __f_` member for the old dylib to use `std::open()`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116045/new/
https://reviews.llvm.org/D116045
More information about the libcxx-commits
mailing list