From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105609 invoked by alias); 17 Jun 2015 09:47:38 -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 105523 invoked by uid 89); 17 Jun 2015 09:47:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 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, 17 Jun 2015 09:47:36 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 94053BC916; Wed, 17 Jun 2015 09:47:35 +0000 (UTC) Received: from blade.nx (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5H9lYn3028567; Wed, 17 Jun 2015 05:47:35 -0400 Received: by blade.nx (Postfix, from userid 1000) id 5D81F262FE6; Wed, 17 Jun 2015 10:47:34 +0100 (BST) Date: Wed, 17 Jun 2015 09:47:00 -0000 From: Gary Benson To: Eli Zaretskii Cc: gdb-patches@sourceware.org, cedric.buissart@gmail.com Subject: Re: [PATCH 1/5] Introduce build_debug_file_name Message-ID: <20150617094734.GA9671@blade.nx> References: <1434447768-17328-1-git-send-email-gbenson@redhat.com> <1434447768-17328-2-git-send-email-gbenson@redhat.com> <83zj3zn21q.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83zj3zn21q.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00354.txt.bz2 Eli Zaretskii wrote: > > From: Gary Benson > > Cc: Cédric Buissart > > Date: Tue, 16 Jun 2015 10:42:44 +0100 > > > > +/* Build the filename of a separate debug file from an arbitrary > > + number of components. Returns an xmalloc'd string that must > > + be be freed by the caller. The final argument of this function > > + must be NULL to mark the end the argument list. */ > > + > > +static char * > > +build_debug_file_name (const char *first, ...) > > +{ > > + va_list ap; > > + const char *arg, *last; > > + VEC (char_ptr) *args = NULL; > > + struct cleanup *back_to = make_cleanup_free_char_ptr_vec (args); > > + int bufsiz = 0; > > + char *buf, *tmp; > > + int i; > > + > > + va_start (ap, first); > > + for (arg = first; arg; arg = va_arg (ap, const char *)) > > + last = arg; > > + va_end (ap); > > + > > + va_start (ap, first); > > + for (arg = first; arg; arg = va_arg (ap, const char *)) > > + { > > + if (arg == last) > > + tmp = xstrdup (arg); > > + else > > + { > > + int len; > > + > > + /* Strip leading separators from subdirectories. */ > > + if (arg != first) > > + { > > + while (*arg != '\0' && IS_DIR_SEPARATOR (*arg)) > > + arg++; > > + } > > + > > + /* Strip trailing separators. */ > > + len = strlen (arg); > > + > > + while (len > 0 && IS_DIR_SEPARATOR (arg[len - 1])) > > + len--; > > Was this logic tested with Windows-style "d:/foo" file names? E.g., > what will happen if the first component is "d:/"? I don't have access to any Windows machine so I haven't been able to test this, but I don't think the new code would regress compared to what it replaces (which doesn't seem to have been written with Windows in mind at all, e.g. it uses "/" rather than SLASH_STRING and has no particular handling for drive letters). For the case you mention nothing would be stripped (the "d" in that path is !IS_DIR_SEPARATOR) so the filename components would be concatenated verbatim, just as with the original code. The resulting filename may not make sense, but it's not a regression. I don't believe this series should be blocked unless it breaks something that actually worked before. Thanks, Gary -- http://gbenson.net/