4 ms·

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

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.

sidkshatriya 2y ago
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.
- dailykoder 2y ago
  While that might be true and the industry has evolved and learned about "better" ways, the old systems still exist. I don't see any reason to complain about it. Yes, we can do better. Yes, we probably should do better. But in some cases you really have to think through every edge case and in the end someone has to do it. So just be grateful for what we have.
  - IshKebab 2y ago
    I don't think this is an "old system" though.
  - alexey-salmin 2y ago
    For old systems -- yes, of course. But designing a new, incompatible API around errno is just backwards.
AndyKelley 2y ago
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.
- kentonv 2y ago
  That seems a bit harsh. Maybe they just wanted it to be a drop-in replacement for glibc...
alexey-salmin 2y ago
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.

sidkshatriya 2y ago

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.

dailykoder 2y ago
While that might be true and the industry has evolved and learned about "better" ways, the old systems still exist. I don't see any reason to complain about it. Yes, we can do better. Yes, we probably should do better. But in some cases you really have to think through every edge case and in the end someone has to do it. So just be grateful for what we have.
- IshKebab 2y ago
  I don't think this is an "old system" though.
- alexey-salmin 2y ago
  For old systems -- yes, of course. But designing a new, incompatible API around errno is just backwards.

AndyKelley 2y ago

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.

kentonv 2y ago
That seems a bit harsh. Maybe they just wanted it to be a drop-in replacement for glibc...

alexey-salmin 2y ago

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.