Quekid5

Yep, once people discover the multitude of JVM flags the cargo culting begins...

It really applies to anything with a huge number of options, I remember similar things from back when I used Gentoo and the wild suggestions I'd get for what exact CC/C++ compiler options to use...

Lack of empathy tends to trickle down, alas.

It's definitely less likely with that technique (in practice!), but still very possible, via e.g. ODR violation or even the classic SIOF.

So, ideally you'd want each separate test case to be compiled separately, but even then you wouldn't be safe! ... because any UB in that test (or the code it's testing!) could lead to a random pass.

UB is good in some ways, but other ways it's really really bad.

EDIT: I will say: If you have a UBSAN turned on for testing, etc. you're reasonably safe... but not fully. There's a lot of stuff they don't catch because it's essentially impossible.

Because this is garbage PR. That's it.

Every property-based testing system (invented ca. 1980) will explore boundary values. The semantics (or lack thereof) of C and C++ can make this difficult to actually test for because the compiler is allowed to say "test passed" to any input leading to UB.

Ask for more regulation.

*Brits

EDIT: Don't get me wrong, my European nation did a lot of bad shit, but don't put the idea of an "expat" on us.

AFAIK, the only correlation with LoC that's got solid evidence is this: the number of bugs correlates with LoC.

Must have 120 fps for answers arriving in [buffering] 30 seconds.

Indeed... why is Anthropic even employing people at all if this AI magic story is true?

You misunderstood their example, I think.

If doesn't matter what 'p' is in their example. The point is: if 'f' is undefined behavior (rather than just impl-defined), then the optimizer concludes that the "if p { f() }" can never happen... which means that we're allowed to assume that 'if p { ... } else { ... }' (in the first part of the example) will always take the else branch. The compiler will optimize accordingly and just always call g() unconditionally.

It was released at "end of life" for Larian patches for BG3, so I can imagine they didn't want to support any old Linux distro. I believe it is technically possible to run it on distros that are "similar enough"[0], but it's pretty pointless if you want to use any PC-only mods, etc.

[0] I still use Arch, btw. :)

Yeah, I've been playing BG3 on Linux[0] for about 2 years at this point (using a Lutris "recipe" or whatever they call it). Ironically, the biggest issues have been with some of the modding tools needing specific versions of DotNet and whatnot. The game itself runs flawlessly.

[0] Arch Linux, btw, because that must be mentioned.

The overhead isn't zero, but with SSDs (and filesystem caches in the gigabytes these days) it's damn near insignificant in pure terms of opening files and such.

Generated tests... I mean... listen to yourself.

I can generate a lot of tests amounting to assert(true). Yeah, LLM generated tests aren't quite that simplistic, but are you checking that all the tests actually make sense and test anything useful? If no, those tests are useless. If yes, I don't actually believe you.

It's the typical 10 line diff getting scrutinized to death, 1000 line diff: Instant LGTM.

Pay attention to YOUR OWN incentives.

However, the best engineers I know are usually among the quickest to open an editor or debugger and use it fluently to try something out.

That's not my experience... mostly it's about first interrogating the actual problem with the customer and conditions under which it occurs. Maybe we even have appropriate logging in our production application? We usually do, because you know, we usually need to debug things that have already happened.

(If it's new/unreleased code, sure fine, let's find a debugger.)

Wikipedia says it was created in 1974, so something's definitely off with the time line here.

Try writing an exhaustive spec for anything non-trivial and you might see the problem.

Analysis Paralysis?

I think wmf's comment in this thread was absolutely correct and succinct, so I won't repeat, but I think it's worth noting that many (all?) of the Wayland devs were actually Xorg devs. Make of that what you will.

Ministry of Truth & Love.

SQLite is public domain while the code released by id/Carmack is GPL.

The latter technically doesn't prevent anyone making money off it, but in practice it does (other than nominal fees).

That alone is a massive difference.

Java's Virtual Threads (JVM 21) + the Structured Concurrency primitives (not sure exactly what's available in Java 21+) do this natively.

Also, a sibling poster mentioned ZIO/Scala which does the Structured Concurrency thing out of the box.

sqrt(2)

Moist run is the way.

It's getting better (in a C++ kinda way), certainly, but...

It's ultimately still driven my matching "random" identifiers (classes, ids, etc.) across semantic boundaries. Usually, the problem is that the result is mostly visual which makes it disproportionately hard to actually do tests for CSS and make sure you don't break random stuff if you change a tiny thing in your CSS.

For old farts like me: It's like the Aspect-Oriented Programming days of Java, but you can't really do meaningful tests. (Not that you could do 'negative' testing well in AOP, but even positive testing is annoyingly difficult with CSS.)

EDIT: Just to add. It's an actually difficult problem, but I consider the "separate presentation from content" idea a bit of a Windmill of sorts. There will always be interplay and an artificial separation will lead to ... awkward compromises and friction.

I think the Referer header kinda-sorta serves as mitigation for 3rd parties just (maliciously) hot-linking to, say, images on your domain, effectively forcing you to bear the cost of upload bandwidth for those images.

(And similar, it's just that images sprang to mind.)

(EDIT: I'm sorry, this silly and dumb.)

"You want many folds!" We gottem!

Assert what, exactly?

Anyway, the larger point is that a re-entrant general solution is desirable. The sort example might be a bit misguided, because who calls sort-inside-sort[0]? Nobody, realistically, but these types of issues are prevalent in the "how to do closures" area... and In C every API does it slightly differently, even if they're even aware of the issues.

[0] Because there's no community that likes nitpicking like the C (or C++) community. I considered preempting that objection :). C++ has solved this, so there's that.

The issue is that many optimization opportunities only appear after monomorphization, inlining, de-virtualization, etc. etc.

Not that you couldn't do source level analysis as you suggest... it just wouldn't be effective in many cases.

It would also be 'unstable' in the sense that it might depend on architecture, etc.

Imagine a comparison function that needs to call sort() as part of its implementation. You could argue that's probably a bad idea, but it would be a problem for this case.

(You could solve that with a manually maintained stack for the context in a thread local, but you'd have to do that case-by-case)