HN user

leni536

4,413 karma

Software Developer, PhD Physicist

hn at lenardszolnoki dot com

Posts11
Comments1,739
View on HN

This first became apparent to me when I got a slide rule. Pi is often marked on the various scales and an x^2 scale is often nearby the x scale.

Capillary action is subject to the same limits as suction at the top. Capillary action can't increase the water pressure at the bottom of the tree.

If you put a straight thin capillary tube upright in water so it sucks up water from the bottom, no matter how thin, it can't draw water up above ~10m of water level.

I am working on it. Floating-point IO is rather heavyweight, so the usual approach of naively slapping constexpr on all the things and putting them in headers can have some observable negative consequences on resource usage during compilation even if you don't use the new constexpr functionality.

To the best of my knowledge fmtlib does implement constexpr formatting for float and double, but not long double.

One reason to use inline assembly is to use instructions that are basically unknown to the compiler, in which case it can't really tell what is being accessed/modified.

Google and Apple are useless for dmca unless you have a court order.

They deserve to also be sued too for the infringement. I don't think safe-harbor applies if they don't act on a valid notice.

There's no way to verify the integrity of the system, and any malicious app can just grab your banking credentials or enable criminals to unlock and drive away with your car.

I don't see how the second half of the sentence follows from the first half.

And a last, most sneaky one: At checkout if you pay with credit/debit card don't use Ryanair's "guaranteed exhange rate" if the cost of the flight is not in your card's currency (ticket by default, at least two clicks to find and untick it). That's ~6% gap from mid-market exhange rate, the worst cards do better than that.

Implementation-defined without further constraining the behavior is not much better than undefined.

Defining it to always error would add overhead even for proper aligned access on x86, as the generated code would need to explicitly check in many cases.

Unaligned access being fine in one architecture, but not in others would create separate dialects, regardless of being blessed by ISO C.

Just don't do unaligned access, it's a dialect that doesn't exist currently, and should never exist.

It's not happening by chance, there is a bug somewhere.

From what I skimmed the package should just call to the js runtime's crypto.randomUUID(). I think it should always be properly seeded.

I think it is extremely unlikely that the runtime has a bug here, but who knows? What js runtime do you use?