From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122647 invoked by alias); 10 Sep 2017 08:19:10 -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 122420 invoked by uid 89); 10 Sep 2017 08:19:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wr0-f178.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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fkMMJDVQGmCSAiavReQMy0i+sU1Z4CPSSj9/PYGIPfk=; b=Drn4MPvsbIDxneFZwv5aN1b0z9fNuIKlxTVWCJavf8gZTmVtK59eaJWHr5my8N0+Yj 5ULpKFtk6ma93N6fdkbck82gNleYdIESN9Kmtg/WINS7NJs4fGi+EK0f+cStJfAstGAC N0NgJne+n0HJ/EKGMHJVGgoxdbm8DRoIlWjMlJtAkm1vKPZhHE2+unwKsVzGqh5WMWfy 9ewpHKMGK4g3odM8LqDWiD4g/Amy7oEO4zjJKbNDvslsODXMaIbh3cGIVdcYa5ZMNByA usocGxuBVQ161exQGlkU1PtQ9ebj3IbH5H852+i+k5sgxrKujHm1RMMRpWtBPcCjENtc PEoQ== X-Gm-Message-State: AHPjjUgqRBFLHEpUAww6B9Jr3Y78mmzu+K4qXQWNSwycV70vvqPsFvbk dJrl0urzXvhcK0sNPn72hA== X-Google-Smtp-Source: ADKCNb6H8NB0I8vefyphlGPo1lHjJP5DdSRYwBVSUvbGTIX12Qfeo7m3YM7/t1aDvYhFYvjKIUsReg== X-Received: by 10.223.169.247 with SMTP id b110mr5472116wrd.31.1505031545501; Sun, 10 Sep 2017 01:19:05 -0700 (PDT) Subject: Re: [PATCH 3/9] posix: Allow glob to match dangling symlinks [BZ #866] To: Paul Eggert , Andreas Schwab Cc: libc-alpha@sourceware.org References: <1504643122-14874-1-git-send-email-adhemerval.zanella@linaro.org> <1504643122-14874-4-git-send-email-adhemerval.zanella@linaro.org> <878thop5fa.fsf@linux-m68k.org> <9455e298-8c48-c42a-0ec3-ffb8d166c69b@linaro.org> <450d2eab-f21a-f90c-6210-ea638787e339@cs.ucla.edu> From: Adhemerval Zanella Message-ID: <403decc7-e039-9be1-fb44-25d611540156@linaro.org> Date: Sun, 10 Sep 2017 08:19: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: <450d2eab-f21a-f90c-6210-ea638787e339@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-09/txt/msg00417.txt.bz2 On 09/09/2017 19:01, Paul Eggert wrote: > Adhemerval Zanella wrote: >> since make also packs >> its own glob copy from gnulib, it is matter to fix on make if and when >> it syncs with gnulib. > > No, GNU Make uses glibc glob if it passes the compatibility tests in > 'configure', which it does. So previously-built instances of GNU make > will likely crash if run with a glibc containing the proposed symlink > changes. Even if you rebuild GNU Make from scratch it will still > crash, because glibc glob will pass GNU Make's tests even with the patch. > > We could fix this by incrementing _GNU_GLOB_INTERFACE_VERSION to 2 > (causing GNU Make's configure-time test to fail), but this is a > serious step that requires changing the libc.so major version number, > creating backwards-compatibility functions for the old behavior, etc. > I doubt whether the symlink glitch with 'glob' is worth all this effort. > > How about the following idea instead: establish two new flags > GLOB_FOLLOW and GLOB_NOFOLLOW, where the caller specifies whether > symlinks should be followed. The default is system-dependent. For > glibc the default is GLOB_FOLLOW (we can even make GLOB_FOLLOW zero). > For FreeBSD the default would be GLOB_NOFOLLOW, assuming they like the > idea of supporting these flags. This maintains backward-compatibility > for both kinds of platforms. For application code preferring > GLOB_NOFOLLOW semantics if available, a simple: > > #include > #ifndef GLOB_NOFOLLOW > # define GLOB_NOFOLLOW 0 > #endif > > will do, as long as all calls go glob specify 'GLOB_NOFOLLOW'. We can > implement this idea first in Gnulib and then propose it for glibc. > > Anyway, I'll submit a bug report to GNU Make, since it should not be > assuming this implementation detail of glibc, regardless of what we > decide about the above matter. However, it will be at best many years > before we can assume this bug is fixed in the wild. I would prefer to avoid adding a new flag, but for this specific issue I do not see a better solution (as you have said I also agree bumping interface version does not worth the trouble). What really bothers me is the motivation to actually support it is to maintain compatibility with a undefined use of a not well documented interface (which imho is clearly a bug in 'make' usage). This will be another adhoc gnu extension, which most likely won't be used anywhere besides on make itself (and the system-dependent semantic will also lead to more confusion). Another option is to add a compat glob symbol with previous semantic (without actually bumping _GNU_GLOB_INTERFACE_VERSION). It still won't help new 'make' builds against newer glibc (not without fixing make anyway), so I am not sure if is feasible solution.