Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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?