Readit News logoReadit News
jmgao commented on Gathering Linux Syscall Numbers in a C Table   t-cadet.github.io/program... · Posted by u/phi-system
jmgao · 2 months ago
> I was expecting a unified interface across all architectures, with perhaps one or two architecture-specific syscalls to access architecture-specific capabilities; but Linux syscalls are more like Swiss cheese.

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.

jmgao commented on Anker goes big with new whole home backup system   theverge.com/news/860392/... · Posted by u/fleahunter
adrianN · 2 months ago
This reads like an ad, but the following passage stood out

> the average US home consumes about 889kWh per month, or about 29.2kWh per day

I assume most of that is HVAC? I use about 1500kWh a year, but I don’t need aircon and heating is district heating.

jmgao · 2 months ago
> I use about 1500kWh a year, but I don’t need aircon and heating is district heating.

That's 171 W on average, that's about the same as my refrigerator (~150 W on average).

jmgao commented on The most famous transcendental numbers   sprott.physics.wisc.edu/p... · Posted by u/vismit2000
BeetleB · 2 months ago
All floating point numbers are rational.
jmgao · 2 months ago
Well, except for inf, -inf, and nan.
jmgao commented on A production bug that made me care about undefined behavior   gaultier.github.io/blog/t... · Posted by u/birdculture
publicdebates · 2 months ago
To those who are just as confused as me:

Compilers can do whatever they want when they see UB, and accessing an unassigned and unassiganble (file-local) variable is UB, therefore the compiler can just decide that *foo is in fact always 42, or never 42, or sometimes 42, and all would be just as valid options for the compiler.

(I know I'm just restating the parent comment, but I had to think it through several times before understanding it myself, even after reading that.)

jmgao · 2 months ago
> Compilers can do whatever they want when they see UB, and accessing an unassigned and unassiganble (file-local) variable is UB, therefore the compiler can just decide that *foo is in fact always 42, or never 42, or sometimes 42, and all would be just as valid options for the compiler.

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.

jmgao commented on A production bug that made me care about undefined behavior   gaultier.github.io/blog/t... · Posted by u/birdculture
nneonneo · 2 months ago
Even calling uninitialized data “garbage” is misleading. You might expect that the compiler would just leave out some initialization code and compile the remaining code in the expected way, causing the values to be “whatever was in memory previously”. But no - the compiler can (and absolutely will) optimize by assuming the values are whatever would be most convenient for optimization reasons, even if it would be vanishingly unlikely or even impossible.

As an example, consider this code (godbolt: https://godbolt.org/z/TrMrYTKG9):

    struct foo {
        unsigned char a, b;
    };

    foo make(int x) {
        foo result;
        if (x) {
            result.a = 13;
        } else {
            result.b = 37;
        }
        return result;
    }
At high enough optimization levels, the function compiles to “mov eax, 9485; ret”, which sets both a=13 and b=37 without testing the condition at all - as if both branches of the test were executed. This is perfectly reasonable because the lack of initialization means the values could already have been set that way (even if unlikely), so the compiler just goes ahead and sets them that way. It’s faster!

jmgao · 2 months ago
There are some even funnier cases like this one: https://gcc.godbolt.org/z/cbscGf8ss

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.

jmgao commented on Rootless Pings in Rust   bou.ke/blog/rust-ping/... · Posted by u/bouk
stavros · 3 months ago
> It's not UDP socket that gets created here, but Datagram socket

A datagram socket is a UDP socket, though. That's what the D stands for.

jmgao · 3 months ago
Wrong way around: UDP sockets are datagram sockets, there are datagram sockets that are not UDP.
jmgao commented on Google Revisits JPEG XL in Chromium After Earlier Removal   windowsreport.com/google-... · Posted by u/eln1
AshleysBrain · 4 months ago
I think the article is slightly misleading: it says "Google has resumed work on JPEG XL", but I don't think they have - their announcement only says they "would welcome contributions" to implement JPEG XL support. In other words, Google won't do it themselves, but their new position is they're now willing to allow someone else to do the work.
jmgao · 4 months ago
Describing it as 'Google' is misleading, because different arms of the company might as well be completely different companies. The Chrome org seems to have had the same stance as Firefox with regards to JPEG XL: "we don't want to add 100,000 lines of multithreaded C++ because it's a giant gaping security risk", and the JPEG XL team (in a completely separate org) is addressing those concerns by implementing a Rust version. I'd guess that needing the "commitment to long-term maintenance" is Chrome fighting with Google Research or whatever about long-term headcount allocation towards support: Chrome doesn't want the JPEG XL team to launch and abandon JPEG XL in chrome and leaving Chrome engineers to deal with the fallout.
jmgao commented on AirPods libreated from Apple's ecosystem   github.com/kavishdevar/li... · Posted by u/moonleay
moonleay · 4 months ago
A cool project, when you want to use AirPods outside of Apples ecosystem. Sadly, you have to use a rooted android device with a small patch due to a bug in the Android Bluetooth implementation. https://issuetracker.google.com/issues/371713238
jmgao · 4 months ago
It doesn't seem obvious to me that this is actually a bug in the Android implementation, it seems like this is due to AirPods violating the spec and requiring a special handshake before responding to standard requests. It doesn't seem reasonable to expect Android to work around a device that appears to be intentionally breaking the spec for vendor lock-in purposes: the possibility of them just OTAing an update that breaks in some other way means that you'd have to be entirely bug compatible with iOS's bluetooth implementation.
jmgao commented on PCB Edge USB C Connector Library   github.com/AnasMalas/pcb-... · Posted by u/walterbell
Taniwha · 5 months ago
jmgao · 5 months ago
I've found 0.8mm to make much more reliable connections, since the specification says that the tongue should be 0.7mm. 0.6mm will disconnect if the cable is angled in any way.
jmgao commented on Bring Your Own Agent to Zed – Featuring Gemini CLI   zed.dev/blog/bring-your-o... · Posted by u/meetpateltech
0x696C6961 · 7 months ago
The vim emulation is very good.
jmgao · 7 months ago
Seconding this, it's the only editor other than emacs that has a vim-mode that feels like it's maintained by a long term vim user.

u/jmgao

KarmaCake day1258February 6, 2012
About
[ my public key: https://keybase.io/jmgao; my proof: https://keybase.io/jmgao/sigs/n5UFQGDv-Rd7VAJM_qdjyATNxOs-n8Z3rIZBV8RFGQU ]
View Original