From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104631 invoked by alias); 16 Sep 2015 22:17:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 104612 invoked by uid 89); 16 Sep 2015 22:17:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 16 Sep 2015 22:17:30 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id DD3A191DCA; Wed, 16 Sep 2015 22:17:28 +0000 (UTC) Received: from localhost (ovpn-116-24.ams2.redhat.com [10.36.116.24]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GMHR82029129; Wed, 16 Sep 2015 18:17:28 -0400 Date: Wed, 16 Sep 2015 22:23:00 -0000 From: Jonathan Wakely To: Martin Sebor Cc: libstdc++ , gcc-patches Subject: Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10. Message-ID: <20150916221727.GF2631@redhat.com> References: <20150911142140.GL2631@redhat.com> <55F311D2.8050405@gmail.com> <55F469CF.9010503@gmail.com> <20150916144207.GY2631@redhat.com> <55F9A8A8.3060502@gmail.com> <20150916185844.GD2631@redhat.com> <55F9E75F.10602@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <55F9E75F.10602@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-09/txt/msg01245.txt.bz2 On 16/09/15 16:04 -0600, Martin Sebor wrote: >>Tested powerpc64le-linux, x86_64-dragonfly4.1 and x86_64-netbsd5.1, >>do you see any reason not to commit this for now? > >I see only a couple of potential problems: a missing test for >PATH_MAX in the unlikely event it's not defined (or is obscenely In the current patch _GLIBCXX_USE_REALPATH won't be defined unless: #elif _XOPEN_VERSION >= 700 || defined(PATH_MAX) so if it's defined and _XOPEN_VERSION < 700 then we know PATH_MAX must be defined (otherwise _GLIBCXX_USE_REALPATH wouldn't be). >large), and a missing check to avoid infinite loops due to symlinks. I thought about keeping track of where I'd been while expanding symlinks, but then realised this will do it: if (!exists(pa, ec)) { fail(ENOENT); return result; } // else we can assume no unresolvable symlink loops If there's a symlink loop then exists(pa) will fail with ELOOP, and we won't try to resolve it by hand. And then after each step in the while(!cmpts.empty()) loop I also have a check for !exists(result, ec), which should even handle the case where the filesystem changes after the initial exists() call so that a loop is introduced while we're canonicalising the path. >>Any improvements such as hardcoding checks for specific versions of >>Solaris or the BSDs are QoI, and this is only an experimental TS, so I >>don't want to spend the rest of stage 1 working on one function :-) > >Makes sense. > >>My main obstacle to writing good tests right now is having some way to >>create and destroy files safely in the tests. It's hard to test >>functions like is_symlink() without first creating a symlink in a >>known location, and also removing it again cleanly so the next >>testsuite run doesn't fail if the file is already present. >> >>One option would be to have libstdc++-v3/testsuite/Makefile create a >>new sub-directory as a sandbox for filesystem tests, removing it if it >>already exists. Then the tests can put anything they like in that new >>dir without fear of trashing the user's files elsewhere on the FS! > >I don't know how you feel about Tcl but writing a filesystem.exp >and adding a new "dg-fs" API would let each test can set up the >directory structure it needs. My Tcl is very weak, but if that's the right approach then I can try that. Thanks again!