From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27620 invoked from network); 24 Jan 2022 19:49:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Jan 2022 19:49:46 -0000 Received: (qmail 17420 invoked by uid 550); 24 Jan 2022 19:49:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16357 invoked from network); 24 Jan 2022 19:49:42 -0000 Date: Mon, 24 Jan 2022 20:53:14 +0100 From: Ismael Luceno To: musl@lists.openwall.com Cc: Rich Felker Message-ID: References: <20220123155955.16484-1-ismael@iodev.co.uk> <20220123155955.16484-3-ismael@iodev.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] [PATCH v3 2/2] nftw: implement FTW_ACTIONRETVAL (GNU extension) On 24/Jan/2022 09:47, Dominique MARTINET wrote: > This didn't get much traction when I submitted one last year: > https://www.openwall.com/lists/musl/2021/03/26/1 > (and there were at least a couple other occurences I could find at the > time) Thanks for reviewing. I was unaware of your submission. > But given it keeps getting resubmitted I assume we can say that confirms > there's demand for it? <...> > > @@ -72,12 +72,19 @@ static int do_nftw(char *path, int (*fn)(const char *, const struct stat *, int, > > if (!fd_limit) close(dfd); > > } > > > > - if (!(flags & FTW_DEPTH) && (r=fn(path, &st, type, &lev))) > > - return r; > > + r = 0; > > + if (!(flags & FTW_DEPTH) && (r=fn(path, &st, type, &lev))) { > > + if ((flags & FTW_ACTIONRETVAL)) { > > + if (r == FTW_STOP) return FTW_STOP; > > + if (r == FTW_SKIP_SUBTREE) return 0; > > + /* other values are saved for when returning */ > > Hm, I'd naively think you would want to return immediately the other > values as well, so the else below is wrong? > But I didn't take long enough to check what e.g. a SKIP_SIBLINGS would > mean here, the construction just looks a bit odd to me. SKIP_SIBLINGS doesn't imply SKIP_SUBTREE, so must be saved and returned when finishing. > > @@ -120,10 +130,13 @@ static int do_nftw(char *path, int (*fn)(const char *, const struct stat *, int, > > } > > > > path[l] = 0; > > - if ((flags & FTW_DEPTH) && (r=fn(path, &st, type, &lev))) > > - return r; > > - > > - return 0; > > + if (flags & FTW_DEPTH) { > > + r = fn(path, &st, type, &lev); > > + /* ignore FTW_SKIP_SUBTREE (too late), the caller is broken */ > > + if ((flags & FTW_ACTIONRETVAL) && r == FTW_SKIP_SUBTREE) > > + return 0; > > IIRC the glibc implementation also ignores FTW_SKIP_SIBLINGS in that > case (nftw returns 0), I'm not sure how much of a 1-to-1 implementation > we want -- I had implemented my version through a black-box approach > with a client exercising all kind of different code paths as for a gnu > extension I'd assume glibc to be the reference. FTW_SKIP_SUBTREE makes no sense with FTW_DEPTH, but FTW_SKIP_SIBLINGS works with both.