31–40 of 94 posts
>Without libc you don’t have to use this global, hopefully thread-local, pseudo->variable. Good riddance. Return your errors, and use a struct if necessary. On contrary you should absolutely use errno, if only to report your IO errors. Or maybe he never does IO. After all a program that doesn't output anything is likely safer, since these are all evil side effects. I can just see that new programming paradigm: "side…
Earlier quoted context omitted.
It really doesn't, though, although in principle Editions could provide an escape hatch it would be so drastic as to be largely unthinkable. Because of Rust's commitment to long term stability all of the standard library is there forever, even if it's a mistake and thus deprecated. std::u8::MAX will be in the library forever, even though you can write u8::MAX to get the same constant, name.trim_left_matches(remove) w…
Hey, don't get me started on semantics... what if you trim from the left or right, but are using RTL. Imagine your surprise when the exact opposite happens.
Earlier quoted context omitted.
errno is thread-local, so you don’t have to worry about context switches.
Historically, it wasn’t (of course; Unix didn’t have multiple threads in a program). https://pubs.opengroup.org/onlinepubs/7908799/xsh/errno.html : “Previously both POSIX and X/Open documents were more restrictive than the ISO C standard in that they required errno to be defined as an external variable, whereas the ISO C standard required only that errno be defined as a modifiable lvalue with type int.” Even now that…
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 is most(ly) convenient in graphics APIs, I don’t know how common leveraging this in the libc actually is.
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?
errno = 0
// code which may error here
if(errno) { … }
This is quite verbose, annoying, and error prone.
When Go showed up on the scene, I was just about losing my patience with libc, and one if the things I found miraculous about Go was "no more strtok and friends".
Earlier quoted context omitted.
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.
This [1] seems to contradict, that at least for more "recent" versions of POSIX. [1]: https://unix.org/whitepapers/reentrant.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/e...
Earlier quoted context omitted.
You do option 3, manually adapt one type to the other because they are different types. If you call one function that returns an int and need to pass it to another function that expects a char* what do you do?
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…
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"
)Earlier quoted context omitted.
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.
Excerpt from C11: "[...] errno which expands to a modifiable lvalue that has type int and thread local storage duration"
Earlier quoted context omitted.
Historically, it wasn’t (of course; Unix didn’t have multiple threads in a program). https://pubs.opengroup.org/onlinepubs/7908799/xsh/errno.html : “Previously both POSIX and X/Open documents were more restrictive than the ISO C standard in that they required errno to be defined as an external variable, whereas the ISO C standard required only that errno be defined as a modifiable lvalue with type int.” Even now that…
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…
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. Similarly here, there's clear value in having them part of the type system, if only to prevent a footgun of someone forgetting to mark a load as atomic/volatile.