public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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>

  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).