Nguyễn Thái Ngọc Duy  [off-list ref] writes:

Some of you may recall a while back, nd/conditional-config-include
failed on Windows because I accidentally fopen()'d a directory in a
test, but it's not considered an serious error unless it's on Windows,
where fopen(<dir>) returns NULL.

A couple of suggestions were thrown back and forth, but I was a bit
busy to follow up. Now that I have time, I have audited all fopen()
calls and try to fix them up for good. There 15 patches, but they only
change one or two lines each. I split them anyway so you can pause
between patches and see if it really makes sense, as changes are all
over the places.

Nicely done.  

I wonder if it is OK to only special case ENOENT for !fp cases,
where existing code silently returns.  Perhaps it is trying to read
an optional file, and it returns silently because lack of it is
perfectly OK for the purpose of the code.  Are there cases where
this optional file is inside an optional directory, leading to
ENOTDIR, instead of ENOENT, observed and reported by your check?