From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7204 invoked by alias); 25 Aug 2017 16:41:06 -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 6755 invoked by uid 89); 25 Aug 2017 16:41:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*RU:209.85.218.66, Hx-spam-relays-external:209.85.218.66, 12722, HContent-Transfer-Encoding:8bit X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-oi0-f66.google.com Received: from mail-oi0-f66.google.com (HELO mail-oi0-f66.google.com) (209.85.218.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Aug 2017 16:41:04 +0000 Received: by mail-oi0-f66.google.com with SMTP id t88so287976oij.3; Fri, 25 Aug 2017 09:41:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RItl4SO43lid0++2UzWF0B3lRahx11gs8L1P8nd5J3Q=; b=SKIC3+TeDqzxoVSlWZmg+wgdx2wLXWyanuLu4/Dk3gwidCgvS3CleEZTo0OczTahlJ angTfExMbVsSpeGonNP6suOu6PQXPVM+4/Pw7xGKNrFABYr3grtGsUib8YqwUyAjqg04 p9pKUwlzkSUTA/AC8CK7aCn6rB8sSwkenq4SDZO5qlh18BshdqM9qYM5MN2WU7TwZPvv 68+y1zXLfMmAodsghtPTsdl0IbWDOylNIBvplrsn9A/CDNTPVs6oSv9UBKsKilaSOCH0 HeVSVJj22Qv19VUqUkJOp/NSJN6F9GbFsu3ket1aoShEMg+LRC8yQbZMJJqEfxN5Erk7 sR1A== X-Gm-Message-State: AHYfb5hvzptf7/o3oT+hlRibQ1riuWWLAaalmffQtv42uWVL7Zcjkc8X BnMGpXkc5EwcK8Zg X-Received: by 10.202.84.138 with SMTP id i132mr12886679oib.111.1503679262347; Fri, 25 Aug 2017 09:41:02 -0700 (PDT) Received: from localhost.localdomain (174-16-125-25.hlrn.qwest.net. [174.16.125.25]) by smtp.gmail.com with ESMTPSA id d95sm7298391oic.14.2017.08.25.09.41.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 09:41:01 -0700 (PDT) Subject: Re: [PATCH] Fix file find utils and add unit tests (PR driver/81829). To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , gcc-patches@gcc.gnu.org References: <6708f658-bebf-07ac-4c68-8729af4e8de1@suse.cz> Cc: doko@gcc.gnu.org From: Martin Sebor Message-ID: Date: Fri, 25 Aug 2017 16:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01509.txt.bz2 On 08/18/2017 04:17 AM, Martin Liška wrote: > On 08/15/2017 02:45 PM, Martin Liška wrote: >> Hi. >> >> As shown in the PR, remove_prefix function is written wrongly. It does not distinguish >> in between a node in linked list and pprefix->plist. So I decide to rewrite it. >> Apart from that, I identified discrepancy in between do_add_prefix and prefix_from_string >> where the later one appends always DIR_SEPARATOR (if missing). So I also the former function. >> And I'm adding unit tests for all functions in file-find.c. I know only very little about this API but from a quick glance at the change it looks to me like it introduces an implicit assumption that prefix points to a non-empty string. If that is in fact one of the function's preconditions I would suggest to a) assert it before relying on it, and b) document it. Otherwise, if the prefix is allowed to be empty then the code below is undefined in that case. Martin @@ -126,11 +127,22 @@ do_add_prefix (struct path_prefix *pprefix, const char *prefix, bool first) /* Keep track of the longest prefix. */ len = strlen (prefix); + bool append_separator = !IS_DIR_SEPARATOR (prefix[len - 1]); + if (append_separator) + len++; + if (len > pprefix->max_le