[libcxx-commits] [PATCH] D116045: [libc++][ABI BREAK] Start using `arc4random()` to implement `std::random_device` on Apple

Wed Jan 5 09:15:54 PST 2022

Mordante added a comment.

In D116045#3220577 <https://reviews.llvm.org/D116045#3220577>, @ldionne wrote:

> In D116045#3206713 <https://reviews.llvm.org/D116045#3206713>, @Mordante wrote:
>
>> I assume software on Mac dynamically links libc++.so and that normally there's only one system version of libc++.so installed. I'm somewhat concerned about this use case:
>>
>> - A user has bought software that uses `random_device("/dev/not_urandom")`
>> - The user update to a new MacOS which has the proposed changes
>> - Now the application terminated due to an uncaught exception
>>
>> When this scenario can happen it's possible to break working software by updating the random device. So I agree that not throwing is a kind of ABI-break, but I consider possibly breaking working code after a system upgrade by the user also an ABI-break and worse than the other.
>>
>> Should we discuss this further on Discord?
>
> Right -- so I tried explaining this in my commit message here:
>
>> This behavior is preferred to ignoring the custom token in order to avoid surprising changes in behavior when a custom token was expected to result in the corresponding file being used for entropy.
>
> Basically, what I'm suggesting is that it's better to fail fast and loud than to be silently incorrect. One could argue that the behavior if we silently ignore the custom token isn't really incorrect, though. I'll ignore the token instead.

I read the original message. I was just wondering whether the change can break a working executables after MacOS update. Just to make sure we considered that case and made a conscious decision to accept that issue. I think it would be good the mention whether or not this can break existing executables in the commit message.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116045/new/

https://reviews.llvm.org/D116045