201984

inline and register still have semantic requirements that are not just hints. Taking the address of a register variable is illegal, and inline allows a function to be defined in multiple .c files without errors.

> What's not helping the situation is the fact that the kernel has no good page allocation API that differentiates between reserving and committing memory.

mmap with PROT_NONE is such a reservation and doesn't count towards the commit limit. A later mmap with MAP_FIXED and PROT_READ | PROT_WRITE can commit parts of the reserved region, and mmap calls with PROT_NONE and MAP_FIXED will decommit.

Password managers can be backed up onto USB drives pretty easily, and copies can be made of paper.

It's much more difficult to make comparable backups of passkeys due to all the "anti phishing" / vendor lock-in rules most platforms have.

And I just found out recently that you can't log into Google on a desktop without responding to a prompt on your Android phone. Which, if you broke said phone, you can't do.

This is without 2fa enabled on my Google account.

It's great until they break their phone, or spill coffee on it, or just lose it, and now they are locked out of EVERYTHING with no good way to get back in.

Passwords on a piece of paper for better or worse do not have that problem.

Then why is Box::leak not marked unsafe?

Do training scrapers really feed all their input through an LLM to decode it? That sounds expensive and most content probably doesn't need that. If they don't, then this method probably works to keep your stuff out of the training datasets.

FlushInstructionCache isn't needed on x86_64. I-cache and D-cache are coherent.

Thanks

What's your reason for -O2 over -O3?

The classic distinction is that a CISC has data processing instructions with memory operands, and in a RISC they only take register parameters. This gets fuzzy though when you look at AArch64 atomic instructions like ldadd which do read-modify-write all in a single instruction.

He's actually wrong on the ABI requiring the top bits to be 0. It only requires that the bottom 32 bits match the parameter, but the top bits of a 32-bit parameter passed in a 64-bit register can be anything (at least on Linux).

You can see that in this godbolt example: https://godbolt.org/z/M1ze74Gh6

The reason the code in his post works is because the upper 32 bits of the parameters going into an addition can't affect the low 32 bits of the result, and he's only storing the low 32 bits.

It's to break dependencies for register renaming. If you have an instruction like

  mov w5, w6 // move low 32 bits of register 6 into low 32 bits of register 5

This instruction only depends on the value of register 6. If instead it of zeroing the upper half it left it unchanged, then it would depend on w6 and also the previous value of register 5. That would constrain the renamer and consequently out-of-order execution.

AArch64 also zeroes the upper 32 bits of the destination register when you use a 32 bit instruction.

Which Apple product is this? Memory dies and logic dies require entirely different factories to make, so I doubt this SoC exists.

"403 Forbidden" error unfortunately.

He does it to get somebody to comment, and it worked this time.

No, that's ridiculous. If I want to send an app to someone, now they have to wipe their phone to install it? That would kill installing non-Play apps far more than Google's original proposal.

Seems the technical accuracy wasn't improved very much, if at all.

Yeah, it's not as detailed for sure. You can set it to show a graph of GPU utilization over the last minute or so, but that's about it.

Lmao, probably. I'm not going to trust anything else this person has written, since this has proven to me he's writing about things he has little experience with.

And that "fix" is not "one flag" any more either since you have to install that compiler somehow.

Did you not even try the original command? As you've now updated it (https://github.com/little-book-of/c/commit/43b0a89852a507bdd...), it is definitely not one simple flag since arm-linux-gnueabihf-gcc has to be installed from somewhere. It doesn't exist in a default installation of GCC that only targets the host, and you'll need to install a GCC version for every architecture you want to target.

Press F2 to go to setup, then go to "Meters" on the left. Under "Available Meters" you should see "GPU usage", which can be added to the status meters at the top. Available options for format are "Bar", "Text", "Graph", and "LED".

I'm using 3.4.1, so it's possible you have an older version that doesn't have it.

It's still just a single hyphen on clang, double hyphen like in the post does not work on clang either.

htop has GPU usage too, it's just not at the top by default.

>You can target an embedded ARM board or a RISC-V chip with one flag:

  gcc main.c --target=arm-linux-gnueabihf -o app

AI hallucination? --target does not exist in GCC. Clang has -target, but you still need to install libc for the target architecture.

Thanks for the explanation!

What do you mean by "toxic slug strategy"?

Fun fact, 1ms is the approximately the amount of time it takes for sound to travel 1 foot. Do musicians move all their speakers to be within one foot of their ears? Do people in a band notice a difference if they're not standing within 1 foot of their partners? No, they don't.