From: Paul Eggert <eggert@cs.ucla.edu>
To: DJ Delorie <dj@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: posix/glob.c: update from gnulib
Date: Wed, 30 Mar 2022 16:40:27 -0700 [thread overview]
Message-ID: <038e38d7-59f3-527b-b6ae-f9b7d8ccdb06@cs.ucla.edu> (raw)
In-Reply-To: <xn4k3fw1f0.fsf@greed.delorie.com>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On 3/30/22 14:55, DJ Delorie via Libc-alpha wrote:
> Copied from gnulib/lib/glob.c in order to fix rhbz 1982608
>
> Used config.h instead of libc-config.h
I don't see why this change is needed. This code is inside "#ifndef
_LIBC" so this change should have no effect for glibc. And the change is
harmful for Gnulib, since for this file Gnulib relies on including
libc-config.h instead of plain config.h.
> The #ifdef around #define dirfd() was changed to #undef due to
> conflicts between glibc's internal and external definitions of
> dirfd(). This has been reported to gnulib.
I updated Gnulib to reflect this change; see first attached patch. That
being said, I don't fully understand it. Wouldn't it be more efficient
for glibc glob to use glibc's internal dirfd by whatever name you prefer?
Anyway, the only difference between what you proposed for glibc and
current Gnulib glob is the second attached patch; could you please merge
that into your proposal? That way, the two glob.c files can be
identical, which is a good thing.
Thanks for following up on this.
[-- Attachment #2: glob-fixups.diff --]
[-- Type: text/x-patch, Size: 434 bytes --]
--- posix/glob.c 2022-03-30 16:18:03.358942602 -0700
+++ ../gnulib-savannah/lib/glob.c 2022-03-30 16:27:43.412646585 -0700
@@ -18,13 +18,13 @@
#ifndef _LIBC
/* Don't use __attribute__ __nonnull__ in this compilation unit. Otherwise gcc
optimizes away the pattern == NULL test below. */
# define _GL_ARG_NONNULL(params)
-# include <config.h>
+# include <libc-config.h>
#endif
#include <glob.h>
#include <errno.h>
next prev parent reply other threads:[~2022-03-30 23:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 21:55 DJ Delorie
2022-03-30 23:40 ` Paul Eggert [this message]
2022-03-30 23:45 ` Paul Eggert
2022-03-30 23:54 ` DJ Delorie
2022-03-31 10:56 ` Adhemerval Zanella
2022-03-31 17:38 ` DJ Delorie
2022-03-31 17:44 ` Adhemerval Zanella
2022-03-31 19:29 ` DJ Delorie
2022-03-31 19:38 ` Adhemerval Zanella
2022-03-31 20:00 ` [v2] " DJ Delorie
2022-04-01 1:55 ` Paul Eggert
2022-04-04 21:25 ` Carlos O'Donell
2022-04-14 23:40 ` [v3] " DJ Delorie
2022-04-27 21:16 ` Carlos O'Donell
2022-04-27 21:21 ` DJ Delorie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=038e38d7-59f3-527b-b6ae-f9b7d8ccdb06@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=dj@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).