Hacker News new | past | comments | ask | show | jobs | submit login

That's a total strawman. Errno has nothing to do with signal handling at all. While errno is archaic, it is a completely sound design.

That you need to be very careful in signal handlers is common knowledge, and obvious from what they do; signals handlers as a first approximation behave like executed in a separate thread, but even worse since they hijack a running thread and thus block the hijacked thread from executing the previously running code. (So you could say they're like fibers / cooperative multitasking?)

The bottom line is, you can't touch errno in your signal handler, obviously -- just like you can't printf() or any other thing that has "critical sections". And since you don't do that, you're safe.

By the way, signal handler safety is specified in POSIX and/or various other documents to a degree that neither I nor you seem to have cared to research properly. https://www.gnu.org/software/libc/manual/html_node/POSIX-Saf...

BTW2: I noticed on that page that errno is explicitly mentioned, but obviously only as an example of modifying thread-local data in a signal handler. As the docs point out, any such modified data must be restored before leaving the signal handler as to not pending code running on that thread. So in that sense, thread-local variable like errno are "safer" for than functions like printf() that take locks -- you _can_ touch them in a signal handler but you need to restore them.




You call it a strawman, I call it knowing what matters when writing portable code across multiple platforms and compilers.

You will notice that I have linked Open Group errno documentation in another post. That is what matters, not what GNU thinks.


So, what does matter? What is your actual statement? That you can't use errno in a multi-threaded environment? That you can't use errno in the presence of signal handlers?

What exactly is your complaint about the GNU link? As far as I can see it more or less regurgitates what POSIX has to say about async-signal-safety.

You made some vague statements that a mechanism that is used on billions of devices is fundamentally unsound, while providing no evidence other than maintaining that it would break in conjunction with signal handlers -- when signal handlers are expressly to be used with caution, no matter what you intend to touch.

If you worry that you can't safely touch errno in a signal handler (provided that you reset it) on some broken platform from decades ago, because a spec like this [0] is too much swallow (understandably so, since this spec is a futile attempt to reconcile all the relevant history into a useful document), then I have a solution... Don't touch errno in a signal handler, which is probably solid practical advice anyway.

Oh, and how do you reconcile the fact that many syscalls are declared async-safe by POSIX that may set errno themselves?

"Operations which obtain the value of errno and operations which assign a value to errno shall be async-signal-safe, provided that the signal-catching function saves the value of errno upon entry and restores it before it returns."

Tada!

[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...


One thing one learns about writing specifications in English is the meaning of must, should and shall.

As for soundness, it is C we are talking about here.


Where "shall" is usually understood as equivalent to "must". Are you going to cite me one reliable source for the adventurous claims you're making all the time, or are you just going to continue putting out blatant falsehoods and strawmans?

> As for soundness, it is C we are talking about here.

Well the only thing we're doing here is trolling, nothing of substance has been put on the plate so far.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: