From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 354571F463 for ; Sun, 5 Jan 2020 16:41:51 +0000 (UTC) Received: from localhost ([::1]:43468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1io8yL-0003wz-Mq for normalperson@yhbt.net; Sun, 05 Jan 2020 11:41:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59827) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1io8yH-0003wg-Ph for bug-gnulib@gnu.org; Sun, 05 Jan 2020 11:41:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1io8yG-0000sq-DR for bug-gnulib@gnu.org; Sun, 05 Jan 2020 11:41:45 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:39802) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1io8yG-0000sV-7m for bug-gnulib@gnu.org; Sun, 05 Jan 2020 11:41:44 -0500 Received: by mail-wr1-f66.google.com with SMTP id y11so47064841wrt.6 for ; Sun, 05 Jan 2020 08:41:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=//MwJXqQgT8OVodJv7mKWBhnOjASYbXH3Z15U2JKTpo=; b=mLAMv9B9jEOkzl7c1O/17BlksEceubHYrUCUGUGouy/YlFnC1MzHwDKnR8sLYTRdI0 H/EU2Vo11qe1IeA07IydFOkAe0fqlgQkzbcj/UIhKVZVSKJo8YcqmxxIE2P3uxvRamDh Fx2LlAae9dLqo5UopF12bv2srybtVkeXarFBe5aKKThG4MO/BFGxL8uzMeovYpCoJoHG rY4mJvGW8jciOl+2hdwm5uacGuCQBW3+9Rq1TLk7OaX2vXiZNpHqx2r4Fu0zA2zGuK2y nngzz24RyJiY6wgHxiNWVRk5dwbQmjBAslVjam0ZaGgR2wpKn5PrpTNe0rLqZzIXCQOx ruSw== X-Gm-Message-State: APjAAAXIq/WJyuu/FYr0IXXpCEWzxrUpp0PWSV4pLgYuW+yCxI24vdhC x0Cx8dTIjKAB4pShmqlCKsh6ht9l78Oy8+eFXP8= X-Google-Smtp-Source: APXvYqzDfezWyHWIN89WXQ95irmtzN37Utu70S3IgNjLUJA0Sv1YZrfSY5OrIDGevgk/PZ41i8PyznmcyCkDk+kI2FQ= X-Received: by 2002:adf:b64b:: with SMTP id i11mr68289059wre.58.1578242502998; Sun, 05 Jan 2020 08:41:42 -0800 (PST) MIME-Version: 1.0 References: <4223468.KeoCiBS5fI@omega> In-Reply-To: <4223468.KeoCiBS5fI@omega> From: Jim Meyering Date: Sun, 5 Jan 2020 08:41:30 -0800 Message-ID: Subject: Re: [PATCH] stdlib: avoid canonicalize_file_name contradiction To: Bruno Haible Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.221.66 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "bug-gnulib@gnu.org List" Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Sun, Jan 5, 2020 at 12:16 AM Bruno Haible wrote: > Hi Jim, Hi Bruno, Thanks for investigating. > > stdlib: avoid canonicalize_file_name contradiction > > * lib/stdlib.in.h (canonicalize_file_name): Remove the nonnull > > attribute from its declaration. > > I'm not sure this is right. The patch removes a diagnostic (from GCC and > possibly other static analyzers) when some code is, by mistake, passing > NULL to canonicalize_file_name. > > The question is: Is passing NULL to canonicalize_file_name valid? If not, > then the nonnull attribute should stay. > > On one hand, in glibc's stdlib.h we have: > > extern char *canonicalize_file_name (const char *__name) > __THROW __nonnull ((1)) __wur; > > On the other hand, in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156#c3 > you say "Note that at least some versions of canonicalize_file_name *can* > take a NULL argument". What are there versions? Even if Cygwin and/or > Solaris 11 have a function of the same name which allows passing NULL, > portable code should not pass NULL since that would not work on glibc > systems. Therefore the diagnostic is useful. It is useful indeed. I noticed this implementation can forward to realpath, which does allow NULL as first argument, then did what must have been an erroneous one-line search for attributes on a glibc system. > > tests/test-canonicalize-lgpl.c > > passes null_ptr () to it, which (via this contradiction) would > > provoke a segfault from GCC 10. See a small reproducer and > > discussion in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156 > > I would prefer to modify the tests, to avoid GCC's over-optimization. > There are two ways to do that: > > * Use 'volatile', as shown by Andrew Pinski in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156#c2 > I am not in favour of this, because the semantics of 'volatile' > changes over time. Currently there is a proposed change in > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2244.htm#dr_476 . > > * The usual technique for this, that we already use in > lib/canonicalize-lgpl.c > lib/getaddrinfo.c > lib/getdelim.c > lib/glob.c > lib/random_r.c > lib/setenv.c > lib/tsearch.c > lib/unsetenv.c > , is to add a line > #define _GL_ARG_NONNULL(params) > before '#include '. > > Does the attached patch fix the problem for you? Thanks for working on that. However, it did not help, because at least on Fedora 30, we're using the system declaration, per this: (run from a test dir prepared by "./gnulib-tool --test --dir /tmp/x --with-tests canonicalize-lgpl", which still segfaults that test) $ rm test-canonicalize-lgpl.o $ make test-canonicalize-lgpl.o CFLAGS='-dD -E' ... $ grep -A2 ze_file test-canonicalize-lgpl.o|head -3 extern char *canonicalize_file_name (const char *__name) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__nonnull__ (1))) ; # 797 "/usr/include/stdlib.h" 3 4