Date: Sat, 27 Aug 2016 21:23:50 +0300 From: Dmitry Selyutin <ghostman.sd@...il.com> To: musl@...ts.openwall.com Subject: readdir(3): behavior on descriptors with O_SEARCH Hello everyone! First of all, thank you for musl; it is an amazing tool and I really glad I'm using it. I'm able to compile and run everything I write (of course if POSIX standard applies). Recently I've found some edge case where both musl-gcc and musl-clang behave differently compared to usual gcc, clang and tcc, and I think the reason lies in the musl library. The example code: int const flags = (O_DIRECTORY | O_SEARCH); int descriptor = open(path, flags); DIR *handle = fdopendir(descriptor); struct dirent *entry = readdir(handle); To cut the long story short, any attempt to call readdir(3) on directory handle obtained via fdopendir(3) returns NULL and sets the errno variable to EBADF. This behavior arises only on descriptors opened with (O_DIRECTORY | O_SEARCH) flags enabled; it goes away if O_SEARCH flag is removed. So it seems that O_SEARCH is the reason; I thought that this flag tells exactly "well, I'm going to use it for search only", which implies "well, I'm going to use only readdir(3) to get information about files inside". Is my interpretation correct? I'm not really sure if it is a bug, since I suspect POSIX may allow open(3) with (O_DIRECTORY | O_SEARCH) flags to behave in an implementation-defined matter; it can be possible that file descriptors obtained via open(3) with O_DIRECTORY flag set are guaranteed to work only with fchdir(3) and *at(3) operations. However, if such behavior is intentional, it would be a good idea (in my opinion) make fdopendir(3) return NULL (though it won't match behavior e.g. for glibc). I don't know if this behavior still matters since I doubt I use the latest musl version; I couldn't find any relevant information about this behavior though. The musl version I'm using is 1.1.15; the code is compiled for x86_64. I'm using the version provided by Arch repositories. I don't have a stable Internet connection now, so I couldn't manage to take a look at the corresponding code in musl; I'll do it as soon as possible and create a patch if my assumptions are correct (and if the above behavior still applies to musl). Thank you for musl and patience (well, it was quite a long letter)! Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.