Am 21.04.2015 um 18:57 schrieb Wietse Venema:
> In that case I think that the bug is that readdir() does not reset
> errno. Rationale: errno is part of the readdir() API, therefore
> readdir() must reset errno so that the caller can distinguish between
> "no more entries" and "there was an error".
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.
There is also normative prose on errno, or errno.h, that no function in
the respective volume of said standard shall reset errno to 0.
If you complain that this is less convenient, I agree, but that's how
errno behaves and why Postfix has grown wrappers around several
functional calls to make their behavior more palatable to the overall
Postfix code.
So the fix appears right to me, only the comments are, well, a bit
misleading...
> We can work around that in Postfix. The workaround is to reset errno
> before calling readdir(), i.e. in the scan_dir_next() function. Not
> in any scan_dir_next() caller, because then we would have to modify
> all the callers of the scan_dir_next() function!
...and I propose to change the comment in the code to read:
...
/* Reset errno so we can tell errors from end-of-directory. */
errno = 0;
...
