I've been on the mailing list for restocks for a month now :-(
This is the only device that I've found that has an e-ink display and an NFC chip that can read cards (there are a few with writable tags).
1,287 karma · joined February 6, 2012
This is the only device that I've found that has an e-ink display and an NFC chip that can read cards (there are a few with writable tags).
If you're only concerned about identical binaries on x86, it's not too bad because AMD and Intel tend to have intentionally identical implementations of most floating point operations, with the exception of a few of the approximate reciprocal SSE instructions (rcpps, rsqrtps, etc). Modern x86 instructions tend to have their exact results strictly defined to avoid this kind of inconsistency: https://software.intel.com/en-us/articles/reference-implemen...
If you want this to work across ARM and x86 (or even multiple ARM vendors), you are screwed, and need to restrict yourself to using only the basic arithmetic operations and reimplement everything else yourself.
There's lots of historical weirdness, mostly around stuff where the kernel went "oops, we need 64-bit time_t or off_t or whatever" and added, for example, getdents64 to old platforms, but new platforms never got the broken 32-bit version. There are some more interesting cases, though, like how until fairly recently (i.e. about a decade ago for the mainline kernel), on x86 (and maybe other platforms?) there weren't individual syscalls for each socket syscall, they were all multiplexed through socketcall.
That's 171 W on average, that's about the same as my refrigerator (~150 W on average).
That's not exactly correct. It's not that the compiler sees that there's UB and decides to do something arbitrary: it's that it sees that there's exactly one way for UB to not be triggered and so it's assuming that that's happening.
The compiler sees that foo can only be assigned in one place (that isn't called locally, but could called from other object files linked into the program) and its address never escapes. Since dereferencing a null pointer is UB, it can legally assume that `*foo` is always 42 and optimizes out the variable entirely.
If the size of the space requested is zero, the behavior is implementation-defined; the value returned shall be either a null pointer or a unique pointer.
I vaguely remember reading somewhere that the MIPS ones are weird to support compatibility with the existing unix syscall numbering, but I can't find any evidence for that anywhere, so maybe it was aspirational or I'm hallucinating.
This definitely would have made it to Pixel 3, per the commit message (https://android.googlesource.com/platform/system/core/+/db64...), it was my primary development device when I implemented this :-)
Everything that's CTS-compliant that got Android 11 should have support: the only change needed from the OEM would be to write a 1 to /config/usb_gadgets/g1/os_desc/use in their USB HAL and there's a CTS test to make sure they did so.