From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10396 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Selyutin Newsgroups: gmane.linux.lib.musl.general Subject: readdir(3): behavior on descriptors with O_SEARCH Date: Sat, 27 Aug 2016 21:23:50 +0300 Message-ID: References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c18fb66913029053b11bbed X-Trace: blaine.gmane.org 1472322254 4224 195.159.176.226 (27 Aug 2016 18:24:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Aug 2016 18:24:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10409-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 27 20:24:09 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bdiH3-0000fI-Kc for gllmg-musl@m.gmane.org; Sat, 27 Aug 2016 20:24:09 +0200 Original-Received: (qmail 30136 invoked by uid 550); 27 Aug 2016 18:24:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30096 invoked from network); 27 Aug 2016 18:24:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=LsJAZwvzgIRFUlVBveHeiiJvjZ4lvFBtRqff4oWY5EM=; b=nV8mZJAtFvsa54ogqNjGlJa9zzE183x+NU7ZbVcOS5Y/w4XKrQME0kSmmjc9OpnjSG jeGs5l6z/0QHPadEa3Q5AFIetWetBJywPwErLLG3lS3xZ5/j+nR1DQzCivQ2SbuaQLzw icly87yQJoLjqNqxQoaYB9PNl+6RNsAphgwHgHaYmwwWGdLDuI8/9QlbgmN7D+8lVD56 j8z/A1tWcJXB0K6xT8ibZ1xmAoU2PCSVPIdKSudVkS5ohZliEtQsXy6iA6DQiqOzmd3I Gh44HpYMoquxmP90xmGOxrP2rHLe8DCh86SSxMLVOI9GXCE9kYPM5FvW4B7ZlY/zcZkf /EYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=LsJAZwvzgIRFUlVBveHeiiJvjZ4lvFBtRqff4oWY5EM=; b=b4v2McAKhlJRnMvgG9bb1gp9sPmb9YpiKqTyVqE2hknzMbNYL6JAl3pkOo0uOEZK2k iGpjVv5099PQGbz3g5ZXKPG+KYZ7Y09KbvrhMl5NTlWupWs+ZpgCJnNU2KKwPpIif1mr 4QsCGopElK0QXv+UIQaKwVH7Da/G87c6nGxy+R3wcxK5sVukzcl3xMYGzPNy6s4YMbRj sh3WHG0aJwf0HMLfH9X1hEhPObJzt+QL9+fGuyhwwRADfdzHxWz7vyCQVQ0pM4pcpOQo dtpwdx6tSw7W2tmlOiliHdDzPIecMzEDOEU+Y7U05/1GUZXxlDuytfXq7h8GYFuIeq0a 8Q1Q== X-Gm-Message-State: AE9vXwPKcl7bOlBQQxf6YzmgCjgA6QrM8rzvB1UMEj3NUvPaxzF7yPr1ojsXuJS3T3IxGnQFYYNoQ+hjach+hw== X-Received: by 10.176.83.15 with SMTP id x15mr5700595uax.68.1472322230888; Sat, 27 Aug 2016 11:23:50 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10396 Archived-At: --94eb2c18fb66913029053b11bbed Content-Type: text/plain; charset=UTF-8 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)! --94eb2c18fb66913029053b11bbed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 a= nd 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 =3D (O_DIRECTORY | O_SEARCH);
int descriptor =3D open(path, flags);
DIR *handle =3D fdopendir(descriptor);
struct dirent *entry =3D 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 err= no 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 re= moved.

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&quo= t;, which implies "well, I'm going to use only readdir(3) to get i= nformation about files inside". Is my interpretation correct?

I'm not really sure if it is a bug, since I suspect POSI= X may allow open(3) with (O_DIRECTORY | O_SEARCH) flags to behave in an imp= lementation-defined matter; it can be possible that file descriptors obtain= ed via open(3) with O_DIRECTORY flag set are guaranteed to work only with f= chdir(3) and *at(3) operations. However, if such behavior is intentional, i= t would be a good idea (in my opinion) make fdopendir(3) return NULL (thoug= h it won't match behavior e.g. for glibc).

I don't know if this behavior still matters since I doub= t I use the latest musl version; I couldn't find any relevant informati= on about this behavior though.

The musl version I'm using is 1.1.15; the code is compil= ed for x86_64. I'm using the version provided by Arch repositories.

I don't have a stable Internet connection now, so I coul= dn'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 l= etter)!

--94eb2c18fb66913029053b11bbed--