From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 381523858D37 for ; Wed, 30 Mar 2022 23:54:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 381523858D37 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-60-KHJUbpIKOkehnaoUFv69Nw-1; Wed, 30 Mar 2022 19:54:25 -0400 X-MC-Unique: KHJUbpIKOkehnaoUFv69Nw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0D6A1806611; Wed, 30 Mar 2022 23:54:25 +0000 (UTC) Received: from greed.delorie.com (ovpn-112-4.rdu2.redhat.com [10.10.112.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC26F40D0160; Wed, 30 Mar 2022 23:54:24 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 22UNsNbv087608; Wed, 30 Mar 2022 19:54:23 -0400 From: DJ Delorie To: Paul Eggert Cc: libc-alpha@sourceware.org Subject: Re: posix/glob.c: update from gnulib In-Reply-To: <038e38d7-59f3-527b-b6ae-f9b7d8ccdb06@cs.ucla.edu> Date: Wed, 30 Mar 2022 19:54:23 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2022 23:54:30 -0000 Paul Eggert writes: >> 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. I was just leaving that line as it was in glibc, but as you note, it shouldn't make a difference. glibc does have a config.h though, and no libc-config.h, which is what made me think this was significant. >> 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? Perhaps, but doing so involved more than just using a macro, because a lot of what the internal macro does depends on having insight into the internals of other modules (like typedef names, for example), which involves other includes (for those typedefs) and such. It was far easier to just leave it alone than to go down that (perhaps shallow ;) rabbit hole. I.e. it was the minimum fix. Since it's just a dereference I don't think it will affect performance. > 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. Done.