On Wed, 2016-10-12 at 20:38 +0200, Petter Reinholdtsen wrote: > According to the POSIX specification, ELIBACC is not in the list of > expected errors from open(). See > <URL: http://pubs.opengroup.org/onlinepubs/009695399/functions/open.h > tml > > for the full specification. You make a good point about ELIBACC not being in the list of errors from open(). But then again, neither is EFAULT.
The point I am trying to express is that open() is being called with valid parameters. But because libeatmydata is not properly initialized, open() is returning EFAULT even though it has been called with valid parameters, which is confusing to the programmer. I think this scenario has mostly been addressed by the fix in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702711. (I suspect but am not certain that there is still a brief race condition in eatmydata_init()). But I also think that even so, in whatever unlikely circumstance that might lead to the EFAULT case getting returned to a calling program, ELIBACC would be a better choice. EFAULT implies a bad address; ELIBACC at least gives me a clue that there is something strange going on with shared libraries. Or maybe in this case EDEADLOCK since I think this can only occur if two threads call open() simultaneously? Or perhaps we could add a mutex around eatmydata_init() and eliminate the possibility of returning EFAULT at all? I'd be happy to submit a patch for that if you think it's a good approach. > Can you provide some example code explaining what kind of error you > believe > should cause open() to return ELIBACC? The patch in http://bazaar.launchpad.net/~mapreri/libeatmydata/drop-unn eeded-include/revision/99 has made it harder to come up with an example that would return EFAULT (ELIBACC). I'd be willing to construct one if you would find it helpful. Thanks for taking the time to look at this.
