Am 22.04.2015 um 01:59 schrieb Viktor Dukhovni: > On Wed, Apr 22, 2015 at 01:50:31AM +0200, Matthias Andree wrote: > >> I would like to chime in here. I believe there is a misunderstanding of >> the API, IEEE Std 1003.1, 2013 Edition aka. The Open Group Base >> Specifications Issue 7 for readdir() explicitly state that on >> end-of-directory, errno is not changed, and applications that need to >> check for errors, should zero it beforehand. > > I also did not expect readdir() to preemptively clear errno.
I was indeed replying to Wietse's PATCH message, not yours, specifically: WV| In that case I think that the bug is that readdir() does not reset WV| errno. Rationale: errno is part of the readdir() API, therefore WV| readdir() must reset errno [...] which isn't covered by POSIX. In Wietse's excuse note that FreeBSD's readdir manual page documents readdir()'s relation to errno only since 9.1-RELEASE. Prior versions are rather unclear; for those, readdir() only fails for invalid seekdir() operation, and what is invalid seekdir() or how it's documented isn't documented either. No talk of errno in seekdir() and readdir() sections, only for closedir(). > The real issue is that NULL returns from readdir(), and many other > functions don't distinguish between normal end of data or no matching > data, and error conditions that lead to the same. These are API > limitations, and the work-around (where the function actually sets > errno on error) is to clear errno, and test it after. > A similar strategy is needed with strtol() for ERANGE, ... Well, this is a particularly cumbersome example, but I agree. It all boils down to if, and if yes, how, you want to tackle the API idiosyncrasies in the Postfix code.
