Disappointing that errors are still signaled by assigning to `errno` (you can apparently override this to some other global, but it has to be a global or global-like lvalue).
The kernel actually signals errors by returning a negative error code (on most arches), which seems like a better calling convention. Storing errors in something like `errno` opens a whole can of worms around thread safety and signal safety, while seemingly providing very little benefit beyond following tradition.
code that uses errno is also a bit harder to understand. I like the way Rust does it -- if a function can fail, it returns a Result.
Disappointing is an understatement. Can't believe these people are making a browser. I'm sure they have some Google-flavored excuse for why to repeat this ridiculous threadlocal errno API.
There's a funny circular dependency in glibc sources because errno lives in the TLS block which is allocated using __sbrk which can set the errno before it's allocated (see the __libc_setup_tls).
The branch that actually touches the errno is unlikely to be executed. However I did experience a puzzling crash with a cross-compiled libc because the compiler was smart enough to inject a speculative load of errno outside of the branch. Fun times.