little reason for it in most FFI either since the stronger types can be used in FFI.
October 1, 2025 at 3:49 PM
little reason for it in most FFI either since the stronger types can be used in FFI.
I don’t remember. I thought it did. But even if not, f(…).into()? Isn’t much worse than f(…)?.
August 11, 2025 at 1:29 PM
I don’t remember. I thought it did. But even if not, f(…).into()? Isn’t much worse than f(…)?.
When your FFI functions return a c_int status, you can instead have them return #[repr(transparent)] struct Res(c_int); and then impl From for Result<(), Error>. This works in stable Rust today.
August 11, 2025 at 5:26 AM
When your FFI functions return a c_int status, you can instead have them return #[repr(transparent)] struct Res(c_int); and then impl From for Result<(), Error>. This works in stable Rust today.
In NIST DRBGs, the potentially-attacker-controlled “m” is the “additional info” (sp? from memory). Look at how they do it. There seem to be optimized ways of doing it, mostly by using simpler keyed constructs (HMAC, HKDF). And some do other ways, also involving a random component.
July 11, 2025 at 6:52 PM
In NIST DRBGs, the potentially-attacker-controlled “m” is the “additional info” (sp? from memory). Look at how they do it. There seem to be optimized ways of doing it, mostly by using simpler keyed constructs (HMAC, HKDF). And some do other ways, also involving a random component.
This sketch of rejection sampling seems like a strawman with the overly simplistic H(ctr||M) construct. Many implementations do rejection sampling without the leakage you mention, by using more sophisticated constructs. The wording misleadingly, dangerously, implies the bad one is the only one. HTH.
July 11, 2025 at 7:11 AM
This sketch of rejection sampling seems like a strawman with the overly simplistic H(ctr||M) construct. Many implementations do rejection sampling without the leakage you mention, by using more sophisticated constructs. The wording misleadingly, dangerously, implies the bad one is the only one. HTH.
It won’t stop all new lints from firing though, just the ones where the suggestions require newer features. if you don’t want CI to fail on the day a new stable Rust is released, more work is needed.
June 26, 2025 at 3:43 PM
It won’t stop all new lints from firing though, just the ones where the suggestions require newer features. if you don’t want CI to fail on the day a new stable Rust is released, more work is needed.
clippy.toml gives you a way to set the MSRV for clippy lints separately from the MSRV of your crate, right?
June 26, 2025 at 6:04 AM
clippy.toml gives you a way to set the MSRV for clippy lints separately from the MSRV of your crate, right?
Make sure your forum wasn’t hacked to serve different content to people who aren’t logged in and/or who aren’t admins and/or from different IPs than what admins typically use.
June 19, 2025 at 7:11 PM
Make sure your forum wasn’t hacked to serve different content to people who aren’t logged in and/or who aren’t admins and/or from different IPs than what admins typically use.
Your issuance numbers probably should be adjusted for lifetime. three consecutive 90-day certificates are equivalent to one 270-day certificate, for example.
June 17, 2025 at 12:59 PM
Your issuance numbers probably should be adjusted for lifetime. three consecutive 90-day certificates are equivalent to one 270-day certificate, for example.
If you refuse to give permission to Parallels to abuse the accessibility features to automate the installation of the update, it will fail to install it (stating the obvious?). But if you go to the macOS developer downloads page, download that system update, and install it manually, it works.
June 10, 2025 at 2:56 AM
If you refuse to give permission to Parallels to abuse the accessibility features to automate the installation of the update, it will fail to install it (stating the obvious?). But if you go to the macOS developer downloads page, download that system update, and install it manually, it works.
As a software developer, I find many aspects of the app’s design to be amazing. It’s actually one the best-designed apps I’ve ever used, especially in sports. Some clunky parts, but overall it is really impressive. It’s been working extremely reliably for me, which is amazing on its own.
June 5, 2025 at 3:56 AM
As a software developer, I find many aspects of the app’s design to be amazing. It’s actually one the best-designed apps I’ve ever used, especially in sports. Some clunky parts, but overall it is really impressive. It’s been working extremely reliably for me, which is amazing on its own.
I am watching a lot of baseball. Too much.
May 29, 2025 at 7:21 AM
I am watching a lot of baseball. Too much.
It seems to be required by the design of core::atomics, like you point out. Presumably it could be upstreamed into libcore proper as well, though I suspect there are some knobs to tweak it that libcore wouldn’t like to expose. Definitely not an easy situation to deal with.
March 28, 2025 at 3:09 AM
It seems to be required by the design of core::atomics, like you point out. Presumably it could be upstreamed into libcore proper as well, though I suspect there are some knobs to tweak it that libcore wouldn’t like to expose. Definitely not an easy situation to deal with.
I mean, this needs a new target spec with a new implementation of core sync atomic, right?
March 28, 2025 at 2:29 AM
I mean, this needs a new target spec with a new implementation of core sync atomic, right?
Can’t you implement atomics by checking the address of the atomic and using a lock stored in coherent memory that guards some kind of (expensive, slow) coherence protocol built on top of the lock?
March 28, 2025 at 12:08 AM
Can’t you implement atomics by checking the address of the atomic and using a lock stored in coherent memory that guards some kind of (expensive, slow) coherence protocol built on top of the lock?
Doesn’t that mean that malloc must avoid allocating from PSRAM, or the target much claim no atomics?
March 27, 2025 at 11:48 PM
Doesn’t that mean that malloc must avoid allocating from PSRAM, or the target much claim no atomics?
It would have been exactly the same as Chrome, except slower to market. That was the problem, and still is the problem with Firefox today.
March 26, 2025 at 3:36 PM
It would have been exactly the same as Chrome, except slower to market. That was the problem, and still is the problem with Firefox today.
I wasn’t involved in the decision making. I did seem to be the one who informed decision makers for the first time that the sandbox would still be needed. I remember that very clearly because the surprised—and, it seemed, doomed—look on people’s faces surprised me.
March 26, 2025 at 3:31 PM
I wasn’t involved in the decision making. I did seem to be the one who informed decision makers for the first time that the sandbox would still be needed. I remember that very clearly because the surprised—and, it seemed, doomed—look on people’s faces surprised me.
Very early on I think memory safety was seen as a lighter-weight substitute for sandboxing. This was before we realized Servo would have so much legacy code in it, and it was before Spectre/Meltdown made it clear it was impossible even without legacy code. (Not sure what the plan was for the JIT.)
March 26, 2025 at 3:20 PM
Very early on I think memory safety was seen as a lighter-weight substitute for sandboxing. This was before we realized Servo would have so much legacy code in it, and it was before Spectre/Meltdown made it clear it was impossible even without legacy code. (Not sure what the plan was for the JIT.)
I simply disable the cancel button so I don’t have to worry about it.
March 20, 2025 at 9:43 PM
I simply disable the cancel button so I don’t have to worry about it.