Making EPERM friendlier

Posted Jan 21, 2013 18:56 UTC (Mon) by apoelstra (subscriber, #75205)
In reply to: Making EPERM friendlier by dtlin
Parent article: Making EPERM friendlier

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

to post comments

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.