From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98084 invoked by alias); 8 Sep 2017 09:16:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 97513 invoked by uid 89); 8 Sep 2017 09:16:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f169.google.com 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=v81Bf85K+DMvMce92uAHHsmpU8hE2hvzjPpYCBQAsGA=; b=cMA2H0XSspSzGtV723dXO5RZtuRvQCu5nmKohW8pHquP/8PH7TczfMfX3lbxXZjJbK ekbcN84azwlcuUqxJ5kUdZuHfBZ5tpiuQBhYML0LWrzs32czJnkoa/lnZDdIMg1pV0Pb +QrdeDQX+4gGBKDuhLZeUNTPuZeaERyS31b3FIW8tXlKld/+UI0JxzbCwIgw5LePHPO/ 64eLibCVsAsexybBKgZ81yztaOSep4lJT0x8LJtJE/B2sjQYifJErf2bkDTJtNBF9hiU 5y0QVxNURRtXoAgDsmcI9thlPcFVHVn8eXzjkacNOLOOsG3iRfALT+pQ2qRIdFAXaS0A UEIA== X-Gm-Message-State: AHPjjUi8LNYOZHAyGhe+mvdkJNSNJuyEI4oEa7ADxAquPK7BdzC8Y5fL fwQXX1xvf0YHay4qLfO91Q== X-Google-Smtp-Source: ADKCNb6c7pdeM43KS49z6SBrn6foy4zymXKCBxBMqC2r/SzR0/F3yXAwauKkj3bP1jTrKxXsSDWv+g== X-Received: by 10.223.138.235 with SMTP id z40mr1418383wrz.14.1504862172800; Fri, 08 Sep 2017 02:16:12 -0700 (PDT) Subject: Re: [PATCH 9/9] posix: Fix glob with GLOB_NOCHECK returning modified patterns (BZ#10246) To: Paul Eggert , libc-alpha@sourceware.org References: <1504643122-14874-1-git-send-email-adhemerval.zanella@linaro.org> <1504643122-14874-10-git-send-email-adhemerval.zanella@linaro.org> <2a8058e8-4859-d75b-a16d-7ea0dd61ffd7@cs.ucla.edu> From: Adhemerval Zanella Message-ID: Date: Fri, 08 Sep 2017 09:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2a8058e8-4859-d75b-a16d-7ea0dd61ffd7@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-09/txt/msg00373.txt.bz2 On 08/09/2017 00:14, Paul Eggert wrote: > Although this is a definite bug and the patch fixes this instance of > it, I'm afraid other instances remain unfixed. For example: > > glob_t g; glob ("//a*b", 0, NULL, &g) > > can do the wrong thing, since glob calls opendir on "/" instead of > "//", and on some platforms "/" and "//" are different directories > (POSIX allows this as a special exception). > > A more serious example. If you do this: > > ln -s /no-such-file globlink1 > ln -s . globlink2 > > then: > > glob_t g; > int res =3D glob ("globlink[12]/", 0, NULL, &g); > assert (res =3D=3D 0 && g.gl_pathc =3D=3D 1); > assert (strcmp (g.gl_pathv[0], "globlink2/") =3D=3D 0); > > fails, since glob gets confused about directories and slashes and > mistakenly returns two results. Although this bug is seemingly > unrelated, the underlying cause is the same: glob gets confused about > whether to include or exclude slashes when doing its tests. > > I'll take a look at it, though the fix won't be trivial. > > PS. This finishes my review of this patchset. Patches 1-8 are OK to be > installed, with the trivial changes I suggested earlier. This patch > (patch 9) I'd like to hold off on, until we've had a chance to work > out a more-comprehensive fix. Fair enough, I will hold patch 9 push and take a look at the examples you brought up. Thanks for the follow up. > > PPS. I'm still slowly wending my way through your original patchset. > Most recently I looked at "[PATCH 07/18] posix: User LOGIN_NAME_MAX > for all user names in glob" > . I'm > afraid a good fix needs to be hairier there too, as POSIX does not > require LOGIN_NAME_MAX to be suitable for a stack-based buffer, or > even to be defined. I have a partly-drafted patch which I hope to > finish in the not-too-distant future. Alright, my initial patch was to adequate it to glibc code (which does define a actual limit suitable to stack allocation) and get rid of any alloca usage. My understanding, based on gnulib commit 064df0b0c, is it should not impose a limit on user name length.=20 So currently in a patchset I am intended to send after this one, user name handling is now based on my char_array struct and thus allocates the user_name dinamically if required.