workingjubilee

I don't think we have to not-believe Chainguard. To me, the problem is more that "in the wild" is a somewhat airy statement that can only be taken to strictly mean that one found it somewhere on a computer that is connected to other computers. This is almost a non-statement, as airgaps are the exception rather than the rule.

Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.

The other procedural languages are also not mystically secure from soundness problems, people just fuzz them less.

I'm not based in China, bro. You're the one who went around accusing random people of being advanced persistent threat actors, and now you can't even keep your story straight.

Do not post blatant lies.

The "small string optimization" makes the strings harder to manipulate with `unsafe` code. However, being easy to manipulate with `unsafe` code is in fact a priority for most std types, so that they are easily understood, extended, rearranged, passed over FFI and then later reconstituted, etc.

You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.

I don't usually express my frustration by shouting at a pile of HTML but this one had me going "LEMME LOOK!"

struggle sessions usually involve public torture or executions. it's laughable to compare "being mildly inconvenienced" with that.

what would "stabilize" mean when the opsem model that miri obeys continues to change?

yeah, g-d forbid that any routine busywork gets automated by software, otherwise all those lines of code might actually have a point!

The Rust calling convention is actually defined as unstable, so 1.79 is allowed to have a different calling convention than 1.80 and so on. I don't think designing one for the long term is a real concern right now.

Allowing developer control over calling conventions is also simultaneous with disallowing optimization in the case that Function A calls Function B calls Function C calls Function D etc. but along the way one or more of those functions could have their arguments swapped around to a different convention to reduce overhead. What semantics would preserve such an optimization but allow control? Would it just be illusory?

And in practice assembly has the performance disadvantage of not being subject to most compiler optimizations, often including "introspecting on its operation, determining it is fully redundant, and eliminating it entirely". It's not the 1990s anymore.

In the cases where that kind of optimization is not even possible to consider, though, the only place I'd expect inline assembly to be decisively beaten is using profile-guided optimization. That's the only way to extract more information than "perfect awareness of how the application code works", which the app dev has and the compiler dev does not. The call overhead can be eliminated by simply writing more assembly until you've covered the relevant hot boundaries.

Your experience is not perfectly transferable. JITs have it easy on this because they've already gathered a wealth of information about the actually-executing-on CPU by the time they generate a single line of assembly. Calls appear on the hot path more often in purely statically compiled code because things like the runtime architectural feature set are not known, so you often reach inlining barriers precisely in the code that you would most like to optimize.

This is a frankly ridiculous assertion given LKML's notoriously toxic history. Part of the problem is that overly-entitled maintainers can be as equally dangerous to actual progress in the project by stonewalling useful code on invented reasons that have never been applied to previous PRs and that the maintainer does not apply to their own commits.

Nice.

aw geez, now we have to compile docs, too?!

Eliminating "custom workflows" seems like rather the point of such an extension.