The ideal way to do runtime-checked DbC is not with simple asserts, it's with proper first-class preconditions and postconditions at the language level.

It wouldn't be nice to have to manually ensure that both old and new states of variables are in-scope for postcondition checking. I can imagine that being not just tedious, but error-prone.

> An Assert merely validates the state of a program at a particular point during execution.

Some aspect of the program's state, yes, and hopefully that's all it does.

Interesting to think about the edge-cases here though. Depending on the language, it could accidentally side-effect, or even invoke undefined behaviour, and so actively derail the program. Can't blame DbC for that though, that's a question of language safety.

> You use it to steer the program to go through only the correct subset of the state space of the program

I'm not sure I follow here. You don't use asserts to steer flow-control, you use them to check aspects of program state.

> You could do this pre/post every executable statement (i.e. write proof of correctness)

That doesn't constitute a proof of correctness, no more than last time you and I discussed this. [0] Depending on the language, it wouldn't even necessarily prove the correctness of that particular trace, as you haven't proven that you haven't accidentally invoked undefined behaviour.

You hold a minority opinion on this, please stop presenting it as settled fact.

> The point is that when using asserts you think about correctness w.r.t. specifications and nothing else. To think of it as simply validating arguments or in terms of effects on optimization is quite the wrong thing to do.

I'm not sure why you'd think I don't already know that.

[0] https://news.ycombinator.com/item?id=44675668

(For what it's worth I didn't downvote you.)

Chromium is open source, but Chrome isn't. Blink, WebKit, and for that matter KHTML, are available under permissive licences.

I tried googling but couldn't find hard numbers on the performance impact of GCC's -fwrapv flag. As you'd imagine, it forces wrapping for overflowing arithmetic on signed integer types. [0]

I also have to wonder how instructive that would be anyway. The GCC devs presumably don't prioritise the performance impact of that flag. If the C language mandated it, they might find other ways to achieve similar optimisation.

This page [1] looks at the related flag for trap-on-signed-overflow, and found an impact of very roughly 6%.

See also: John Regehr's posts on this topic. [2][3] He dislikes Java's implicit wrap behaviour, as it's rarely what the programmer wants to happen. Java programmers almost never use the addExact method, [4] as it's so syntactically clumsy.

> surely it's UB because some systems trapped on overflow, or produced different results due to using 1's complement, and the optimization side of the rule was a happy accident

Per this StackOverflow answer [5] I think you have it right.

[0] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

[1] https://danluu.com/integer-overflow/

[2] https://blog.regehr.org/archives/1401

[3] https://blog.regehr.org/archives/1154

[4] https://docs.oracle.com/en/java/javase/25/docs/api/java.base...

[5] https://stackoverflow.com/a/18195756

Heh, yes that's exactly what I was thinking when I put roughly speaking.

> where a kind C compiler might just mess with your numbers a bit, an evil C compiler can legally make demons fly out of your nose

Yes, signed integer overflow being another. Presumably it's defined that way as it's simpler than trying to spell out all the behaviours the compiler is permitted to implement, and on top of that there are trap representations to worry about. I doubt modern compilers get much optimization benefit from it though. There's a StackOverflow thread discussing the reasons it's defined this way: https://stackoverflow.com/q/1860461

No, that's not right. It's undefined behaviour, not merely an unspecified order of evaluation. Roughly speaking, the behaviour of the entire program is unconstrained by the language standard after execution of that statement. It could crash the whole process, for instance, or go haywire.

(Again, that's in C, apparently, but not in C++.)

It's common for interview questions to explore unusual code, perhaps poor quality code, that hinges on edge cases of the language. A candidate with a strong understanding of the language would be expected to take the opportunity to demonstrate it.

From https://openjdk.org/jeps/483 :

> This program runs in 0.031 seconds on JDK 23. After doing the small amount of additional work required to create an AOT cache it runs in in 0.018 seconds on JDK 24 — an improvement of 42%.

I'm not sure about that. Knowing assembly is not a substitute for knowing how the language is defined. Sometimes C/C++ programmers with some assembly knowledge reason themselves into thinking that what they're asking of the language must have well-defined behaviour, when in fact it's undefined behaviour. It doesn't really matter whether interleaving order can change the output. (++i)++ is, apparently [0], undefined behaviour in C but has well defined behaviour in C++.

[0] https://stackoverflow.com/a/58841107

https://en.wikipedia.org/wiki/Modules_(C%2B%2B)

This is quite plainly not the case. If curve grading is used, cheating directly harms other students who aren't cheating. If curve grading isn't used, the university may end up handing out high grades like candy, and that's a problem for the university.

Higher grades can translate to better career outcomes even if undeserved. If it were clear that this wasn't the case, nobody would cheat in the first place.

Static typing is, roughly, where variables and expressions have fixed types that can be determined ahead of execution. Strong typing means the language doesn't offer implicit type conversions. Python is dynamically typed, i.e. not statically typed, and strongly typed. (Ignoring its type annotations feature, of course.)

Isn't readability what matters here? Conciseness isn't the same thing.

This is pretty much a distinction without a difference. There are licences that qualify as one but not the other (per the FSF and OSI's determinations), but none are in widespread use.

> When you fork Free Software, your fork is also Free Software.

That would be copyleft. [0] Not all Free Software licences are copyleft licences.

[0] https://en.wikipedia.org/wiki/Copyleft

SSH fingerprints are derived from the public key. https://superuser.com/a/453022

Looks like I'm mistaken on terminology though. x86 includes the 16-bit, 32-bit, and 64-bit ISAs of that family, and doesn't refer specifically to the 32-bit generation.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

As fhn points out, there are now truly open video codecs available (open specification, royalty free, unencumbered by patent terms) that are able to compete with the patent-encumbered ones on technical merit. Seems curious that the patent-holders would want to hike prices in this way and validate the motivation behind the truly open codecs.

Also, the article mentions the licensing fees for H265 were also increased recently. It doesn't seem to give a figure, a quick web search turns up 25% [0] or perhaps 20% [1]. Perhaps I'm missing something obvious but I'm not clear on how the change in price relates to the patent dispute between Nokia and certain laptop manufacturers.

(It seems the H264 fee increase affects streaming providers only, whereas the H265 fee increase did not, as it affected laptop manufacturers.)

[0] https://news.ycombinator.com/item?id=46004129

[1] https://news.ycombinator.com/item?id=46003285