sherincall

> completely impossible with printf

Not printf exactly, but I've found bugs with a combination of mprotect, userfaultfd and backtrace_symbols when I couldn't use HW breakpoints.

Basically, mark a set of pages as non-writable so that any writes trigger a pagefault, then register yourself as a pagefault handler for those and see who is doing the write, apply the write and move on. You can do this with LD_PRELOAD without even recompiling the debugee.

For whatever it's worth it to you, I've been with NVIDIA for over 10 years and I wouldn't switch to F,A,A,N nor G for even 2x my total comp. Feel free to shoot any questions to [email protected] if it'll help you decide.

Or, just talk to your hiring manager(s) about the dilemma. For both companies, it'd be better to talk through any concerns before joining. If you accept one offer and then regret it a few months later, everyone loses: you, NVIDIA and [FAANG].

Because of stock appreciation, they'd need to pay up to 10x what the other company is already paying.

Consider a senior SWE at e.g. NVIDIA making $300k, let's say halfsies split between base and RSU. The $150k RSU grant from a few years ago that still hasn't fully vested is worth $1M now. So even for a 50% increase in nominal total comp, it doesn't make financial sense to switch.

I don't know that anyone can afford to pay their engineers 10x more than the competition, and then also offer a cheaper product with thinner margins.

C language makes a difference between Undefined Behavior and Implementation Defined Behavior. In this case it's the former (n1570 section 7.24.2.1).

Any code that invokes UB is not a valid C program, regardless of implemention.

More practically, ignoring the bug that did happen, libc also has multiple implementations of these functions and picks one based on HW it is running on. So even a statically linked glibc could behave differently on different HW. Always read the docs, this is well defined in the standard.

The memcpy API says that is Undefined Behavior, that program was never valid. Not much different from bitbanging specific virtual addresses and expecting they never change.

For overlapping memory, use memmove()

Yes, you're totally right, my math is way off.

Be that as it may, existing software that used to work will no longer work, and the developers might not be around/able to fix it.

There are also cases of custom suballocators or arrays of objects - Looking at an address makes it possibly to figure out which array it belongs to. This code would break.

Granted, it would still be possible to do all this if you just mask off the tag bits, but it requires a software change.

The estimated number of atoms on earth is on the order of 1e50, which is 60 bits. If you take the 4 bits out of the 64bit address for tagging, you can still address individual atoms.

EDIT: My math is bad, see comments below.

I can unsarcastically say that no one will ever need full 64bit addresses on this planet.

I don't think it is fair to pin this on steam. Plenty of games on steam run without steam, and require no installation - just copy them over to a different PC. They often come with binaries for all supported OSes at once, so your windows install will work on linux too.

It is the game publishers that choose to use steam drm. Often the same publishers publish on GOG without the drm (since gog, admirably, does not offer a drm option to them), but it is not steam that is forcing the drm on you. Your issue is with the game publisher.

Certainly. And I hope same thing happens with nim. All I'm advising against is people betting their livelihood on nim reaching critical mass before a single unexpected event happens that removes the benevolent dictator from the picture. Or at very least be aware of it and make an informed decision.