2,091 karma · joined March 10, 2021
What Every C Programmer Should Know About Undefined Behavior https://blog.llvm.org/2011/05/what-every-c-programmer-should...
My understanding is that enterprise plans don't offer those subscriptions, so they end up paying for API prices and models like these directly impact that revenue stream.
It is not, and that's the issue. If it was just "high level assembly" there would be no UB, and no need to have UB. Instead you have UB (although arguably not all of it is really needed) because you need optimizations, which in turn you need because otherwise C would be too slow for that "operating system" job.
> code which is called thousands of times per second
Scripting languages can easily have loops running thousand of times per second and even more. You're off by some order of magnitudes here if you want to describe operations that happen in operating systems.
- It would have been very annoying if it didn't work like this
- Auto-traits also leak through private fields, so you would have the same issue if you e.g. wrapped the concrete return type in a new type and returned that one instead.
I guess you could type check the bodies of only these functions, or duplicating this work in the dependencies, but this will likely have further complications especially since this will also apply to all `async fn`s.
As for whether this change will make it in, the devil is as always in the details and will depend on whether this solution can work for all the edge cases in the language.
How is moving to iOS's model not nerfing the OS?
No, the important part is that the proof is proving what you think it's proving, meaning you only care about the statement being proved (i.e. the signature/type of the proof term), not the proof itself. Generally the statement will be much smaller than the proof, so manually checking it (or manually writing it) is much more viable than checking/writing the proof.
> I have installed a Lean environment and it seems trivial to misname something, to mistake the order of arguments, to compare to the wrong value. There are infinitely many Lean programs that check but don’t do what they say they do, like every other language.
Sure, that's why you have the check that the statement being proven is what you want it to be. Then any error in the proof _will_ be captured by the type checker.
The point is that you don't need to do that. It shouldn't matter whether the proof is the one you think it is or not, only that it is a proof.
> that has literally zero bugs, however strong the type system of the language it’s writing in.
If by "bug" you mean a logic error that makes the proof invalid then Lean will catch that. Some code successfully type checking in Lean is a guarantee there are no such "bugs" (modulo bugs in Lean itself, but Lean is human written, the core is rather small, and most of it was manually proven to be sound).
It's not something irreplaceable but it's not trivial either.
Because it has the same issue.
SELECT DISTINCT and GROUP BY are equivalent from a query planner perspective.
That's what is generally suggested when handling money, at least for normal businesses (in finance related businesses you might have to handle a lot more decimal places for things like exchange rates, fractions of cryptos etc etc)
Be careful though that some currencies require more than 2 decimal places.
You also didn't give anything to opensource. This shows that AI can allow open source to be used in more cases and in more flexible ways, but in no way does this mean that open source (and especially the good high quality one) will explode.
If anything we saw an explosion of open source projects, most of them low quality slop, and even the ones that used to be high quality are slowly degrading.
Note that the result of 0.1+0.2 does not lie in the interval containing 0.3, which is was confuses most people. The issue is that there is some imprecision in representing 0.1 and 0.2 too, and that compounds when summing, resulting in something that does not actually correspond to 0.3 (hence the classic 0.1+0.2!=0.3)
> 0.2+0.1
0.2+0.1 with floating point numbers _is_ deterministic, as you'll always get the same answer.
I suspect you might instead mean exact calculations/answers (in the example above, neither 0.1, 0.2 nor 0.3 have exact representations using floating point numbers).
And just to be clear, there are non-determinism-like issues with floating point numbers, but those are much rarer/niche and _can_ be fixed. For example parallel summation depends on the order the summation was made, so non-determinism in the parallel implementation ripples through the summation result. Some non-basic operations (e.g. trigonometric operations) have platform dependent implementations with different roundings, so you might experience different result based on the platform you're on.
And they are probably right. But they are probably also missing that this will translate to worse quality. You know, the classic "you can only pick two among good, cheap and fast"
I have never seen Apple approving within 24 hours
They might also have unionized due to the bad conditions while developing GTA 6, which could also lead to it being a bad game. Who knows though.
It tries to argue that higher reward rates are necessary to attrach customers that pay a lot (for credit card companies) and that lower income people are generally subsidized by taxes (obvious but unrelated), but at no point (until where I read) it seems to address the issue of merchants having to generally increase prices due to these cards.
The article did an awesome job explaining what are the parties involved and you choose to use a generic term instead.
> dealing with fraud and chargebacks
A lot of that is offloaded to the merchant, which instead has to pay them on top of what they already pay to the issuer bank.
Note that usually you mount many solar panels, not just one, so this will stack relatively quickly.
- the size of the pointed type - the alignment of the pointed type - a function pointer for its drop glue
That's already quite big to inline to save on indirection, and this is before adding more methods.
Just to expand on this: which vtables will be needed is not known before running codegen. At that point however multiple codegen units might generate the same vtable, and that might not get deduplicated by a later pass.
Moreover with dynamic linking (especially on Windows) it's impossible to guarantee that such vtables will be unique.
Everything is possible, what matters is how much work you have to do to achieve and maintain it.
> You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.
On the other hand Rust uses less memory if you store 0 polymorphic pointers, while C++ still pays the cost of storing a vtable pointer for each object instance.
Effectively C++ choose a design that optimizes for having a lot of polymorphic pointers, while Rust optimized for supporting polymorphism for all objects at no extra cost if you don't use it.