This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] zic, various tests: use 64-bit stat/ftw/readdir functions
- From: Nick Alcock <nix at esperi dot org dot uk>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>, Paul Eggert <eggert at gnu dot org>
- Date: Mon, 26 Jun 2017 18:47:37 +0100
- Subject: Re: [PATCH v2] zic, various tests: use 64-bit stat/ftw/readdir functions
- Authentication-results: sourceware.org; auth=none
- References: <87k23zhvas.fsf@esperi.org.uk> <alpine.DEB.2.20.1706261721520.30222@digraph.polyomino.org.uk>
On 26 Jun 2017, Joseph Myers said:
> On Mon, 26 Jun 2017, Nick Alcock wrote:
>
>> Index: glibc/io/bug-ftw2.c
>> ===================================================================
>> --- glibc.orig/io/bug-ftw2.c 2017-06-26 11:32:54.460712810 +0100
>> +++ glibc/io/bug-ftw2.c 2017-06-26 11:33:38.730559302 +0100
>> @@ -69,7 +69,7 @@
>> {
>> mtrace ();
>>
>> - ftw (".", callback, 10);
>> + ftw64 (".", callback, 10);
>>
>> if (! sawcur)
>> {
>
> A test of ftw should arguably be using ftw exactly, not ftw64, and
> probably be paired with a corresponding tests (using a shared test
> skeleton) that tests the same things for ftw64. I.e., adding appropriate
> checks so this test doesn't fail for 64-bit inode numbers might be better,
> to avoid changing what function this test tests.
i.e. UNSUPPORTED-out this test iff it EOVERFLOWs, and have another
bug-ftw64-2.c that uses ftw64 instead and is run unconditionally?
(And similarly for the other non-64 ftw tests, probably all using the
usual macro-expansion-and-#include trick to keep code duplication down.)
Makes considerable sense: I'll look at that shortly.