7 ms·

>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

by nn3 4y ago

>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 effect free programming" taking over the world in storm. Just based on that gaffe I'm not sure I can take anything else in that post seriously. It's clearly not based on any practical experience.

AaronFriel 4y ago
It's not a gaffe, it's moving C in a direction that's safer and more like modern languages by removing mutable global state. That's what this means: "Return your errors, and use a struct if necessary."
michaelhoffman 4y ago
He is saying that the design of errno is a flaw and that errors should be returned via other means. Not that you can safely ignore errno.
aidenn0 4y ago
Lots of APIs allow reporting of I/O errors without use of an errno-like construct.
- wahern 4y ago
  > Lots of APIs allow reporting of I/O errors without use of an errno-like construct. libc included--the C11 threads API returns some errors directly using the constants thrd_busy, thrd_nomem, and thrd_timedout. Unfortunately, it also uses a catch-all constant, thrd_error, for other errors. The pthreads API returns errno values directly as return values, but that's POSIX, not C.
manv1 4y ago
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.
- actually_a_dog 4y ago
  That’s all documented in the standard though. Why would you access errno any other way?
  - masklinn 4y ago
    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 and restore errno around uncontrolled calls. This is quite verbose, annoying, and error prone.
    - lelanthran 4y ago
      > 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) { … } 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.
  - aardvark179 4y ago
    Consider you are trying to do a foreign function call from an interpreted language. You make the call and then want to check errno to see what the error was, but you don't know what precise C calls the runtime may have made in the meantime, or whether it might have reset errno. The only reliable thing to do is to mark library functions explicitly as modifying errno, and storing that somewhere else so that you can reliably retrieve that value. It's a pain, and if it's not done correctly by everyone then it leaves you with subtle intermittent bugs.
iExploder 4y ago
practice reading with understanding mate

by nn3 4y ago

AaronFriel 4y ago

It's not a gaffe, it's moving C in a direction that's safer and more like modern languages by removing mutable global state. That's what this means: "Return your errors, and use a struct if necessary."

michaelhoffman 4y ago

He is saying that the design of errno is a flaw and that errors should be returned via other means. Not that you can safely ignore errno.

aidenn0 4y ago

Lots of APIs allow reporting of I/O errors without use of an errno-like construct.

wahern 4y ago
> Lots of APIs allow reporting of I/O errors without use of an errno-like construct. libc included--the C11 threads API returns some errors directly using the constants thrd_busy, thrd_nomem, and thrd_timedout. Unfortunately, it also uses a catch-all constant, thrd_error, for other errors. The pthreads API returns errno values directly as return values, but that's POSIX, not C.

manv1 4y ago

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.

actually_a_dog 4y ago
That’s all documented in the standard though. Why would you access errno any other way?
- masklinn 4y ago
  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 and restore errno around uncontrolled calls. This is quite verbose, annoying, and error prone.
  - lelanthran 4y ago
    > 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) { … } 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.
- aardvark179 4y ago
  Consider you are trying to do a foreign function call from an interpreted language. You make the call and then want to check errno to see what the error was, but you don't know what precise C calls the runtime may have made in the meantime, or whether it might have reset errno. The only reliable thing to do is to mark library functions explicitly as modifying errno, and storing that somewhere else so that you can reliably retrieve that value. It's a pain, and if it's not done correctly by everyone then it leaves you with subtle intermittent bugs.

iExploder 4y ago

practice reading with understanding mate