Making EPERM friendlier

Posted Jan 21, 2013 10:17 UTC (Mon) by etienne (guest, #25256)
Parent article: Making EPERM friendlier

I do not get why there is a problem.
Right now errno is an address of an errno_t area of memory.
Why not increase a bit the area to write:
- a signature confirming the extended errno_t
- the size of this errno_t
- what service created the error
- a better description of the error
- a serial number?
It would be fully backward compatible.

to post comments

Making EPERM friendlier

Posted Jan 21, 2013 10:24 UTC (Mon) by mpr22 (subscriber, #60784) [Link] (5 responses)

Congratulations, you just broke switch (errno) { /* ... */ }.

Making EPERM friendlier

Posted Jan 21, 2013 11:45 UTC (Mon) by johill (subscriber, #25196) [Link] (4 responses)

Not really. As far as I understand he's basically saying

struct ext_err_no {
  int /* or whatever */ errno;
  // ... extended info ...
};

struct ext_err_no errno_storage;

#define errno &errno_storage.errno

(I'd guess this could be made to work and still be compliant)

The question of course is how to determine that the extended info is there?

Making EPERM friendlier

Posted Jan 21, 2013 18:47 UTC (Mon) by dtlin (subscriber, #36537) [Link] (3 responses)

I'm pretty sure etienne was not suggesting that, because if you had been reading the article, this breaks existing programs.

do_something_that_might_fail();
{ /* maybe inside an interrupt, logging routine,
   * or anything else that happens between where
   * the error occurs and its consumer */
  errno_t saved_errno = errno;
  do_something_else();  /* might change errno */
  errno = saved_errno;  /* so put errno back */
}

Now you've just clobbered a single field in errno_storage, which might have been saving information from a different call. If you make the variable errno encompass the entire extended storage space, then that code is fine, but then you can't treat it as an int, which is certainly used in many places too.

Making EPERM friendlier

Posted Jan 21, 2013 18:56 UTC (Mon) by apoelstra (subscriber, #75205) [Link] (2 responses)

Suppose you took errno to be an index into a giant array of extended error structures. Then that should be okay?

Making EPERM friendlier

Posted Jan 22, 2013 7:22 UTC (Tue) by itvirta (guest, #49997) [Link] (1 responses)

That only worked if the two functions returned distinct error codes, if they both return EPERM then the same problem appears.

Btw, this is the first I've heard of errno_t, apparently on the systems I checked, errno is defined as just (extern) int errno. Where does errno_t come from?

Making EPERM friendlier

Posted Jan 22, 2013 14:00 UTC (Tue) by etienne (guest, #25256) [Link]

> Where does errno_t come from?

I do not remember where I have seen it first, probably someone defined it locally when going from 32 bits int to 64 bits int, but a bit of internet search leads to:
In the world of Standard C, the type 'errno_t' is defined by TR24731-1 (see http://stackoverflow.com/questions/372980/ for more information) and you have to 'activate it' by defining '__STDC_WANT_LIB_EXT1__'.

Note that increasing the size of the memory referenced by errno is fully backward compatible with already compiled software. My comment was a bit early on Monday morning, to activate a "bigger" errno you would need to define something like '__STDC_WANT_BIG_ERRNO__' before including "errno.h", and check a 32 bits signature just after the old standard code if you may run on a LIBC which do not provide the big errno.