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 C2C311F463 for ; Sun, 5 Jan 2020 21:52:52 +0000 (UTC) Received: from localhost ([::1]:45534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioDpL-0006cr-AH for normalperson@yhbt.net; Sun, 05 Jan 2020 16:52:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38501) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioDpH-0006cf-MW for bug-gnulib@gnu.org; Sun, 05 Jan 2020 16:52:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioDpG-0004Dt-F1 for bug-gnulib@gnu.org; Sun, 05 Jan 2020 16:52:47 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:45964) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioDpG-0004BH-9C for bug-gnulib@gnu.org; Sun, 05 Jan 2020 16:52:46 -0500 Received: by mail-wr1-f67.google.com with SMTP id j42so47635514wrj.12 for ; Sun, 05 Jan 2020 13:52:46 -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=N6wY67SguT8wyeQFtsnWxNNSgucX19mIGdGhquVPEq4=; b=DkD0pV7biR2fBCQSFdWRZOC6NL+IREQpKAbUM0BwOsVNpgvWtd6k/mSIbKi4lmsdfr dq8whDWzrbH3iA+7Cb5AvjH5F8Ii8Rdx1tX7V5cdOql0yasb/lmH9MpOQiOBLdpt72cs mr7RGI1+XC4MwAXiBK88NtJi9PHKCzui3oZtRagJCacrCCPhsdauTxTbpLxxOzYAqK0l 0qgU+gKfCIwtl5K0mDXhp+W+JXj6Xso44l7DbICfR87f8GhPO2BamvIelG4BExXcFNyy t7s3JwdO2/XHfFzGFyYGIojVW30+qT55TnWPfPdSCjSKmNYa1BR589XZcP+6JENgUlZ1 HNjA== X-Gm-Message-State: APjAAAXS1VBtsLJSSArKn7XVYms/drZjUMSWOdnWehtWV9dkyNk8reV7 RtTAHERk9eNloAL6XNGn6VkuhJ80MvYSW0moF7d7bw== X-Google-Smtp-Source: APXvYqxL0jsCvB8yQVXG8UOJPLruZF7+o3av96b40ocMy+1hQchyK80rhoU8jJP9LfW3C+AQHHMwMU7WAXjlSyy4/Z4= X-Received: by 2002:adf:8b4f:: with SMTP id v15mr71496694wra.231.1578261165172; Sun, 05 Jan 2020 13:52:45 -0800 (PST) MIME-Version: 1.0 References: <4223468.KeoCiBS5fI@omega> <6027532.2bkh7ZSKZP@omega> In-Reply-To: <6027532.2bkh7ZSKZP@omega> From: Jim Meyering Date: Sun, 5 Jan 2020 13:52:33 -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.67 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:47 PM Bruno Haible wrote: > > Jim Meyering wrote: > > > 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. > > OK, then let's preserve it. > > > Thanks for working on that. However, it did not help, because at least > > on Fedora 30, we're using the system declaration > > In this case, since the glibc headers (in particular ) do not > give us the means to influence what __nonnull expands to, we have no choice > than to disable the test when the function comes from the system. > > We do try to check the system functions just like we check the gnulib functions; > this strategy has led us to find numerous libc bugs on various systems. But > here, there's no way. Since canonicalize_file_name and ptsname_r are glibc > inventions, not POSIX functions, there is no specification that tells what > should happen if someone passes a NULL pointer to them; therefore the > __nonnull declaration and the effect that it has (from GCC), namely execute > arbitrary code, cannot be formally disputed. They can be disputed from the > point of view of practical usefulness, though. > > I've pushed this. I hope it fixes the problem. > > > 2020-01-05 Bruno Haible > > tests: Avoid GCC over-optimization caused by _GL_ARG_NONNULL attributes. > Reported by Jim Meyering in > . > * lib/stdlib.in.h (GNULIB_defined_canonicalize_file_name): New macro. > (GNULIB_defined_ptsname_r): New macro. > * tests/test-canonicalize.c (_GL_ARG_NONNULL): Define to empty. > (main): Disable the NULL argument test if canonicalize_file_name does > not come from gnulib. > * tests/test-canonicalize-lgpl.c (_GL_ARG_NONNULL): Define to empty. > (main): Disable the NULL argument test if canonicalize_file_name does > not come from gnulib. > * tests/test-ptsname_r.c (_GL_ARG_NONNULL): Define to empty. > (test_errors): Disable the NULL argument test if ptsname_r does not come > from gnulib. Thanks for those fixes. With those and the three multithread-test-disabling changes, I confirm that all of GNU sed's tests pass when built using the latest from gcc master (GCC10-pre).