41–50 of 94 posts
I ended up writing my own functions in an 'ascii' namespace to avoid all this as much as possible.
This [0] rant about locales and how they're nigh-on impossible to use correctly is quite amusing (slightly NSFW)
[0] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
Earlier quoted context omitted.
I think you may have lost track of what this thread is discussing. To be more concrete, let's say you have the following code (pseudo-Go): package main import "example.com/http_server" // v2 import "example.com/utils" // transitively depends on http_server v1 function main() { var srv *http_server.Server = http_server.New() utils.ServeHttp(srv) } You're going to have a problem, because ServeHttp expects an HTTP serve…
> there's no way to import both the v1 and v2 APIs at the same time in your code, so you don't have a way to declare a conversion function. In Go major versions have different import paths. You can import multiple major versions of the same library: import ( http_server_old "example.com/http_server" http_server_new "example.com/http_server/v2" )
In C and C++, it's idiomatic to have different major versions use the same includeable name, with the version resolution handled by the build system.
Earlier quoted context omitted.
If you don't understand why errno is bad then it'll be hard to explain it. Errno is fine if you're accessing it right after a stdlib function that sets it, because it's the equivalent of a function's error code. Once you get out of that context errno becomes less and less useful and probably shouldn't be used, because without that context you won't know who/what actually set it.
That’s all documented in the standard though. Why would you access errno any other way?
It's a pain, and if it's not done correctly by everyone then it leaves you with subtle intermittent bugs.
Earlier quoted context omitted.
Excerpt from C11: "[...] errno which expands to a modifiable lvalue that has type int and thread local storage duration"
Still doesn't cover signals, only works if C11 threads are being used (it is all open if OS threads follow the same TLS mechanism), and those C89 and C99 code bases get nothing from it anyway.
You can't call OS functions from a signal handler so I can't see why signals would matter. Have I missed something?
Earlier quoted context omitted.
That library functions don’t reset errno is considered a feature / convenience, it allows calling a bunch of them then checking if the entire thing succeeded or failed. Obviously this assumes the failure of one function does not trigger a UB down the line, and that you care about general but not specific failure. And also obviously this is easy to replicate with an API which returns error objects / codes. IIRC this i…
It also requires code to explicitly set errno many, many times. I think there are many errors lurking in C code there, with code calling foo , not checking errno or checking it but not resetting it, later calling bar , and assuming errno was set by bar .
Yes, errno should be cleared every time you want to check it. Although you can check it multiple times with a single clear, as long as a set errno leads to an exit.
A more likely cause if the issue you outline is that errno is not context-local tho, so if you call something which causes errno to be set you might get an errno from an unexpected error. This is similar to overly broad exception contexts, but much harder to diagnose.
> As with volatile, C is using the type system to indirectly achieve a goal. Types are not atomic, loads and stores are atomic I don't get this argument. This same wording can actually be used to make pointers untyped: "pointers are not inherently typed, loads and stores are typed. (In fact, LLVM IR recently made pointers untyped too)". And yet, clearly there's value in having them typed at the language level. Simila…
Making C even more bare bones than it already is makes no sense.
Earlier quoted context omitted.
errno is thread-local, so you don’t have to worry about context switches.
You won't find that on either ISO C nor POSIX specifications. It only happens to be implemented that way in some environments, as a macro to either thread local or some function call that retrieves the right errno. Still, even that doesn't take care about signal handling.
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.
What are the alternatives to these libc functions? Making C even more bare bones than it already is makes no sense.
Earlier quoted context omitted.
That’s all documented in the standard though. Why would you access errno any other way?
The main issues with errno are you need to remember to reset it before you enter a context whose failability you care about, so any code which relies on errno must be: errno = 0 // code which may error here if(errno) { … } And that errno is notably not scoped, so the code which may error should only be composed of calls to libc, or code whose interaction with libc you understand perfectly, otherwise you need to save…
> errno = 0 > // code which may error here > if(errno) { … }
Which are the functions that set errno, and only errno, on failure?
In practice, you will clear errno once, and then repeatedly check for failure after every call to a libc function.
> And that errno is notably not scoped, so the code which may error should only be composed of calls to libc, or code whose interaction with libc you understand perfectly, otherwise you need to save and restore errno around uncontrolled calls.
I don't understand what this means.