The flag is -Wformat-nonliteral or -Wformat=2. -Wformat-security only includes a weaker variant that will warn if you pass a variable and no arguments to printf.
5 years seems like a low for Apple device longevity. I think that there’s an enormous difference between today’s Macs and Macs from 5 years ago and maybe the leap is accelerate deprecation, but there was a long period of stagnating macOS requirements. Hope we return to that for Apple Silicon Macs.
> We could stop right here but this suffers from overflow limitations if translated into C.
FWIW, the final version also suffers from integer overflow limitations. If the difference between an and INT_MIN/INT_MAX (depending on whether you floor or ceil) is <= b/2, you will have integer overflow.
In context, it sounds like they relied on simulations that don’t use exact numbers. I’m guessing that they saw an IEEE-754 floating-point infinity and then had to determine whether they got it because the accurate result was infinity or if the infinity they saw was the result of floating-point calculation artifacts.
I feel that it’s so simple that many people will overlook that it even exists. In languages that have both, it’s hard for functions to compete with operators. I don’t think that this is the best design to promote correctness.
The “battle of preparedness” for grandmasters looks miserable. My experience being bad at chess is pretty cool, though.
If anyone’s looking to pick up chess, it’s a pretty good time to do it even if the people making a living out if it aren’t enjoying it anymore. It used to be that computers would only crush you without helping, but now they’re able to point at your mistakes and show you where the game shifted from one player to the other.
Yes, but your 1995 Windows NT 4.0 PC ran a 640x480 display at 60Hz and graphics compositing had, at best, one-bit transparency. It took 3 minutes to boot. Websites could bluescreen it with `<img src="con">`. A malicious attachment could trick your email client into deleting your whole hard drive.
This is fairly old. When it came up last time, there were robust arguments that xz was characterized unfairly, and that the author’s format wasn’t very good at recovering in most cases either.
No, logic bug consequences are fundamentally different from memory corruption bugs. A bug with an access check for one resource in the kernel means you get access to that specific resource. A missing bounds check in the kernel—anywhere in the kernel—means you get arbitrary code execution. Sure, _sometimes_ you can escalate from one resource to another with an access check issue, but that’s a _sometimes_. One memory corruption bug _anywhere_ defeats the protection of _all resources, all the time_. Not only that, but memory corruption bugs have well-understood exploit recipes that attackers can make once and reuse any time they find a new bug to save work, whereas an attacker has to write a new distinct exploit for most logic bugs.
There is no equivalence to make. Memory corruption bugs are unambiguously, unequivocally better exploitation primitives than logic bugs.
No one is claiming that memory-safe languages solve logic problems. The claim is that most memory corruption bugs are conveniently exploitable and any exploit can reach for anything in the address space, and logic bugs often can’t. You could as well say that you’d rather promote chess pawns to knights instead of queens. Like, that makes sense sometimes, but it’s a bad default.
What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel instead. I don’t mean that you can’t write bugs in memory-safe languages, but in the end the attacker still has to play by your rules. With a memory safety bug, attackers play by no one’s rules.
That’s not really a “but” to the comment, which was that you need to find one bug and it’s game over. We’ve known for a long time that best practices aren’t enough to prevent memory corruption in large enough C++ code bases, so it’s likely a motivated attacker would eventually find something.
The intent of the post isn’t to claim that any Fuschia device currently sold is vulnerable. Unless Fuschia never graduates to running third-party code, that seemed like the right assessment to me.
One data point from the Prodfiler folks was that even if the GC cost to throughput is relatively low, some programs will still spend up to 25% of their time doing garbage collection. This will show up on your cloud bill even if it doesn’t show up to that extent in your performance analysis.
For a while, there would be a macOS notification suggesting that you try Safari after updating. This notification should be gone with the latest macOS. Are you talking about something else?