aw1621107

7 ms·

31.
by aw1621107 2mo ago
> Carbon seems to have gone nowhere. At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1
32.
by aw1621107 2mo ago
Previous HN discussion here ( https://news.ycombinator.com/item?id=42231489 ); 2024-11-24, 554 points, 653 comments
33.
by aw1621107 2mo ago
> But it still depends on the requirements of the specific user project, whether the default is sufficiently fast I mean, "by default" means " by default ", not "in all cases". Situations that the default do
34.
by aw1621107 2mo ago
> It claims to be "sufficiently fast by default", yet "sufficiently fast" depends entirely on the requirements of a specific user project. I think that's why the "by default" is there; the goal is to of
35.
by aw1621107 2mo ago
> However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust? I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out? If Rust differs from C++ in a
36.
by aw1621107 2mo ago
Oil self-sufficiency isn't quite as simple as oil production > oil exports because not all crude is the same and refineries generally aren't completely crude-type-agnostic. IIRC US refineries prefer processing "heavy"
37.
by aw1621107 2mo ago
I'm not sure you need to? Rust references don't exist in C, after all. That being said I wouldn't be surprised if there were other factors that would weigh against considering FFI calls to Fil-C safe by default (e.g., Fil-C&#
38.
by aw1621107 2mo ago
> Depends on a specific definition of "sanitizer" though. Hrm, I suppose a general definition would be something that you use to check for certain (unintended?) runtime behaviors? Though I also feel that could include hardened
39.
by aw1621107 2mo ago
Multiple mutable pointers are fine. You need to be careful to ensure you don't turn them into multiple coexisting mutable references, though.
40.
by aw1621107 2mo ago
> IANAL but is CircuitSeuss not committing a crime here by giving the advice > "If you are discussing illegal shit, don’t do it around people or devices you don’t completely trust. Retain plausible deniability." > Or is
41.
by aw1621107 2mo ago
> Which would imply that's not the case, i.e., that we're not considering every pointer in every GC sweep. I think "every one of those pointers has to be followed on every cycle" as a blanket statement is not correct.
42.
by aw1621107 2mo ago
> Not being able to exhaustively test simple problem absolutely means you can't exhaustively test massively more complex problem. "Simple"/"complex" doesn't necessarily imply "small"/&quo
43.
by aw1621107 2mo ago
> If we only traced young objects Careful; just because you only collect in the new generation doesn't mean that you only trace the new generation. From my understanding a rudimentary generational GC design is to include the old gen
44.
by aw1621107 2mo ago
Just because you can't exhaustively test one thing doesn't mean you can't exhaustively test anything.
45.
by aw1621107 2mo ago
I was thinking that CDSChecker [0]-like tools like Rust's Loom [1] might be able to prune the write+checkpoint search space enough to make exhaustive checking feasible, though I'm far from knowledgeable enough about the implementa
46.
by aw1621107 2mo ago
I mean, exhaustive tests are one way you can prove something.
47.
by aw1621107 2mo ago
> what if this bug is still there but the timing window is now one CPU instruction? I think a model checker or something similar that can exhaustively cover a search space would suffice, though at that point I think the boundary between
48.
by aw1621107 2mo ago
Ah, I see. Thanks for taking the time to elaborate!
49.
by aw1621107 2mo ago
What recent change(s) were made?
50.
by aw1621107 2mo ago
Making signed overflow EB would preclude using signed overflow for optimization though, which seems to be (correctly or not) considered an important use case.
51.
by aw1621107 2mo ago
> It just becomes less a "sanitizer" you can always recommend everyone everywhere use, and more of just a heuristic thing that only really works if you design your code for its arbitrary desires. Sure, and that's basically
52.
by aw1621107 2mo ago
> Of course, -fsanitize=unsigned-integer-overflow isn't enabled by default, and few people use it Sure, but it's still a counterexample for "you can't define it because it means sanitizers can't warn for it"
53.
by aw1621107 2mo ago
> and also allows sanitizers to continue to flag it to developers so that they fix their bugs I've never really found this argument particularly convincing; as you say, sanitizers don't have to strictly adhere to the standard,
54.
by aw1621107 2mo ago
For lack of the creativity needed for better wording (and hoping I'm not inadvertently going in circles here) - how so?
55.
by aw1621107 2mo ago
Neither of those appear to say anything about treating floating point operations as associative nor reordering them as a standard optimization, let alone allowing the programmer to opt into such an optimization.
56.
by aw1621107 2mo ago
> those optimisations are available on the respective JITs. I'd assume they aren't applied by default and/or without the programmer explicitly opting in to those altered semantics, though. Would you be able to show otherwi
57.
by aw1621107 2mo ago
> But what problem is this then really solving? Well, I'd presume that's what the paper's "Introduction & Motivation" section is for. Do you take issue with the authors' statements there?
58.
by aw1621107 2mo ago
> Compiler interoperability is the only ABI related problem area that's remotely in the scope for the C standard idk, given how ABI impacts the evolution of C I think it's not unreasonable to provide a mechanism by which ABI ca
59.
by aw1621107 2mo ago
Not yet , at least. There's a paper in the works [0] and it's been continually updated for the past few years so at the very least it doesn't look like this approach has been outright rejected by the committee. [0]: https:&
60.
by aw1621107 2mo ago
I'm... a bit confused? I wasn't thinking about inter-compiler interop at all.

More ›