This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 00/18] posix: glob fixes and refactor
On 17/08/2017 16:51, Paul Eggert wrote:
> On 08/17/2017 10:32 AM, Adhemerval Zanella wrote:
>> My understanding from Florian comment is the 'decoupled' version would be the
>> code with both win32/amiga/etc code striped and LIBC defines set to only glibc.
>> Would it be acceptable for gnulib?
>
> We don't need Amiga code any more. MS-Windows support is still used, though. However, the current style in glob.c with the forest of ifdefs is pretty bad, and it'd be good to see it go. Instead, I'd rather have the Gnulib-specific stuff put into a section that is relatively independent of the rest of the code. To do that, I suggest that you just rip out all the MS-Windows code, and I'll do my best to reintroduce it in a cleaner way.
Right, I will remove both amiga and win32 code in a subsequent patch to
gnulib sync.
>
>> This would also remove the d_ino/d_type abstraction macros.
> We'll still need some form of abstraction. For fts.c Gnulib is using something like the following, and we could do this sort of thing in glob.c too. It's not much of a burden to write 'D_INO (dp)' instead of 'dp->d_ino' in the mainline code.
>
>
> #if defined _LIBC || defined D_INO_IN_DIRENT
> # define D_INO(dp) (dp)->d_ino
> #else
> # define D_INO(dp) 0
> #endif
I think it is feasible, I will check this out.
>
> By the way, I've lost track: have you looked at the Gnulib fixes for glob.c, and merged them into your glibc patch?
>
By [01/18] patch [1], I synced with 1dc82a77fa606e18edf (which is
still latest gnulib glob version), with some exceptions:
1. Commit 44c637c (Properly initialize glob structure with
GLOB_BRACE|GLOB_DOOFFS) which fixes BZ# 20707.
2. No inclusion of flexmember.h header and its usage on glob.
The code is meant to be rewritten and header is not required in
following patches in this set.
3. An additional define (GLOB_COMPAT_BUILD) to avoid building
size_and_wrapv and gblo_use_alloca twice on some configurations
(i368 compat code) due multiple inclusion.
[1] https://sourceware.org/ml/libc-alpha/2017-08/msg00441.html