From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109299 invoked by alias); 13 Sep 2017 22:46:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 109289 invoked by uid 89); 13 Sep 2017 22:46:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Sep 2017 22:46:55 +0000 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 mx1.redhat.com (Postfix) with ESMTPS id 4CF0E5D687 for ; Wed, 13 Sep 2017 22:46:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4CF0E5D687 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=sergiodj@redhat.com Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26D775D764; Wed, 13 Sep 2017 22:46:53 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches Subject: Re: [PATCH 1/4] Make gdb_dirbuf local to functions References: <20170912042325.14927-1-sergiodj@redhat.com> <20170912042325.14927-2-sergiodj@redhat.com> <0e75c4bf-c9ec-7a07-f1e0-c9d7f11dd136@redhat.com> <87a81yz26g.fsf@redhat.com> <0e5b1e93-20fa-b6ee-f7b9-eec4f8a50064@redhat.com> Date: Wed, 13 Sep 2017 22:46:00 -0000 In-Reply-To: <0e5b1e93-20fa-b6ee-f7b9-eec4f8a50064@redhat.com> (Pedro Alves's message of "Wed, 13 Sep 2017 23:19:27 +0100") Message-ID: <8760cmz06a.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00367.txt.bz2 On Wednesday, September 13 2017, Pedro Alves wrote: > On 09/13/2017 11:03 PM, Sergio Durigan Junior wrote: >> On Wednesday, September 13 2017, Pedro Alves wrote: > >>>> --- a/gdb/cli/cli-cmds.c >>>> +++ b/gdb/cli/cli-cmds.c >>>> @@ -380,6 +380,8 @@ quit_command (char *args, int from_tty) >>>> static void >>>> pwd_command (char *args, int from_tty) >>>> { >>>> + char gdb_dirbuf[BUFSIZ]; >>> >>> I don't recall offhand -- what's "BUFSIZ"? What defines it >>> and is it guaranteed to be the right size for getcwd? >> >> BUFSIZ is defined by stdio.h, and is 8192 on my Fedora 25. This is much >> greater than the previous "1024" that was being used before. > > Ah, that BUFSIZ. That's the FILE* stream buffer size [1], so I don't > see it makes sense to use it for paths over PATH_MAX. It happens to be > greater that 1024 on your system, but that's not guaranteed, no? > > [1] - http://pubs.opengroup.org/onlinepubs/9699919799/functions/setbuf.html > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html AFAIK that's not a guarantee, indeed. Although "1024" is also a very low value for path names on some systems (for example, here PATH_MAX is defined as 4096), we already had this problem before. >> For reproducibility reasons I didn't want to use PATH_MAX. > > I don't understand this. Can you expand? What's not reproducible > about PATH_MAX? How's that different from BUFSIZ? > >>> As an extension, on GNU/Linux, you can call 'getcwd (NULL, 0)' and >>> that returns a heap-allocated buffer of the necessary size. Can we >>> rely on gnulib to implement that behavior everywhere? Since >>> it seems like we're xstrdup'ing the dir anyway, that likely would >>> simplify things, and remove one arbitrary hardcoded limit, while >>> at it. >> >> That's true, and it's better when you consider reproducible builds as >> well. > > /me confused about that. > >> >> According to gnulib: >> >> https://www.gnu.org/software/gnulib/manual/html_node/getcwd.html >> >> It is better to rely on this better version of getcwd. > > Alright. This makes the above moot, though I'd still like to > understand the reproducibility argument, since I suspect that > may come back in other cases. Well, maybe this is more a question of portability than reproducibility, but I mentioned the latter because I remember doing some fixes in some Debian packages that were failing the reproducible tests due to the presence of PATH_MAX. They were actually failing to build on certain targets, but that can be seen as non-reproducibility as well. PATH_MAX is defined by POSIX but is not used by every system. GNU/Hurd, for example, doesn't define it. As usual with GNU programs the "correct" thing to do is not to rely on some hard-coded limit imposed by a header file, but rather to make use of the fact that glibc's getcwd offers the possibility to allocate the variable that holds the path according to its actual size. There are some other problems with PATH_MAX, e.g., the fact that the maximum length of a pathname is really defined by the underlying filesystem you're using, so just using "4096" doesn't really reflect the reality. Again, maybe I should have said "portability issues", but I consider them reproducibility issues as well. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/