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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 7248F3857005 for ; Thu, 27 Aug 2020 08:14:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7248F3857005 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-577-0tMTUFtRMaGbf_olM8-Ufw-1; Thu, 27 Aug 2020 04:14:44 -0400 X-MC-Unique: 0tMTUFtRMaGbf_olM8-Ufw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 28CFB10ABDA1; Thu, 27 Aug 2020 08:14:43 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-37.ams2.redhat.com [10.36.112.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D2217A40C; Thu, 27 Aug 2020 08:14:42 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH 1/4] Sync getcwd with gnulib References: <20200826210246.2830973-1-adhemerval.zanella@linaro.org> Date: Thu, 27 Aug 2020 10:14:40 +0200 In-Reply-To: <20200826210246.2830973-1-adhemerval.zanella@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Wed, 26 Aug 2020 18:02:43 -0300") Message-ID: <87ft881p5b.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 27 Aug 2020 08:14:47 -0000 * Adhemerval Zanella via Libc-alpha: > +#if HAVE_MINIMALLY_WORKING_GETCWD > + /* If AT_FDCWD is not defined, the algorithm below is O(N**2) and > + this is much slower than the system getcwd (at least on > + GNU/Linux). So trust the system getcwd's results unless they > + look suspicious. > + > + Use the system getcwd even if we have openat support, since the > + system getcwd works even when a parent is unreadable, while the > + openat-based approach does not. > + > + But on AIX 5.1..7.1, the system getcwd is not even minimally > + working: If the current directory name is slightly longer than > + PATH_MAX, it omits the first directory component and returns > + this wrong result with errno = 0. */ > + > +# undef getcwd > + dir = getcwd_system (buf, size); > + if (dir || (size && errno == ERANGE)) > + return dir; This conflicts with the getcwd_system implementation does not set errno. > + /* Solaris getcwd (NULL, 0) fails with errno == EINVAL, but it has > + internal magic that lets it work even if an ancestor directory is > + inaccessible, which is better in many cases. So in this case try > + again with a buffer that's almost always big enough. */ > + if (errno == EINVAL && buf == NULL && size == 0) > + { > + char big_buffer[BIG_FILE_NAME_LENGTH + 1]; > + dir = getcwd_system (big_buffer, sizeof big_buffer); > + if (dir) > + return strdup (dir); > + } > + /* When we've iterated through all directory entries without finding > + one with a matching d_ino, rewind the stream and consider each > + name again, but this time, using lstat. This is necessary in a > + chroot on at least one system (glibc-2.3.6 + linux 2.6.12), where > + .., ../.., ../../.., etc. all had the same device number, yet the > + d_ino values for entries in / did not match those obtained > + via lstat. */ > + if (d == NULL && errno == 0 && use_d_ino) > + { > + use_d_ino = false; > + __rewinddir (dirstream); > + d = __readdir (dirstream); > + } I'm not sure if it's worthwhile to have such code in glibc. The generic getcwd isn't used by Hurd, right? Would it make sense to have a trimmed-down Linux implementation as well? Thanks, Florian