[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Making EPERM friendlier

Making EPERM friendlier

Posted Jan 22, 2013 7:22 UTC (Tue) by itvirta (guest, #49997)
In reply to: Making EPERM friendlier by apoelstra
Parent article: Making EPERM friendlier

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?


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds