From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: Jim Meyering <jim@meyering.net>
Subject: Re: [PATCH] stdlib: avoid canonicalize_file_name contradiction
Date: Sun, 05 Jan 2020 09:15:50 +0100 [thread overview]
Message-ID: <4223468.KeoCiBS5fI@omega> (raw)
In-Reply-To: <CA+8g5KGoCEJ=gohDCR=UOHGHDy4fodC6yR7ny-Fz5tJEBOAUFA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
Hi Jim,
> 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.
> 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 <config.h>'.
Does the attached patch fix the problem for you?
Bruno
[-- Attachment #2: 0001-tests-Avoid-GCC-over-optimization-caused-by-_GL_ARG_.patch --]
[-- Type: text/x-patch, Size: 3073 bytes --]
From 826a16e3da3d42454417e433774dda6e5003ad04 Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Sun, 5 Jan 2020 09:13:25 +0100
Subject: [PATCH] tests: Avoid GCC over-optimization caused by _GL_ARG_NONNULL
attributes.
Reported by Jim Meyering in
<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00040.html>.
* tests/test-canonicalize.c (_GL_ARG_NONNULL): Define to empty.
* tests/test-canonicalize-lgpl.c (_GL_ARG_NONNULL): Likewise.
* tests/test-ptsname_r.c (_GL_ARG_NONNULL): Likewise.
---
ChangeLog | 9 +++++++++
tests/test-canonicalize-lgpl.c | 5 +++++
tests/test-canonicalize.c | 5 +++++
tests/test-ptsname_r.c | 5 +++++
4 files changed, 24 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index 6d9ea9e..556549c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2020-01-05 Bruno Haible <bruno@clisp.org>
+
+ tests: Avoid GCC over-optimization caused by _GL_ARG_NONNULL attributes.
+ Reported by Jim Meyering in
+ <https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00040.html>.
+ * tests/test-canonicalize.c (_GL_ARG_NONNULL): Define to empty.
+ * tests/test-canonicalize-lgpl.c (_GL_ARG_NONNULL): Likewise.
+ * tests/test-ptsname_r.c (_GL_ARG_NONNULL): Likewise.
+
2020-01-04 Bruno Haible <bruno@clisp.org>
mbsnrtoc32s: Add tests.
diff --git a/tests/test-canonicalize-lgpl.c b/tests/test-canonicalize-lgpl.c
index b46ad87..2c743af 100644
--- a/tests/test-canonicalize-lgpl.c
+++ b/tests/test-canonicalize-lgpl.c
@@ -16,6 +16,11 @@
/* Written by Bruno Haible <bruno@clisp.org>, 2007. */
+/* Don't use __attribute__ __nonnull__ in this compilation unit. Otherwise gcc
+ may "optimize" the null_ptr function, when its result gets passed to a
+ function that has an argument declared as _GL_ARG_NONNULL. */
+#define _GL_ARG_NONNULL(params)
+
#include <config.h>
#include <stdlib.h>
diff --git a/tests/test-canonicalize.c b/tests/test-canonicalize.c
index e7138a6..1df3092 100644
--- a/tests/test-canonicalize.c
+++ b/tests/test-canonicalize.c
@@ -16,6 +16,11 @@
/* Written by Bruno Haible <bruno@clisp.org>, 2007. */
+/* Don't use __attribute__ __nonnull__ in this compilation unit. Otherwise gcc
+ may "optimize" the null_ptr function, when its result gets passed to a
+ function that has an argument declared as _GL_ARG_NONNULL. */
+#define _GL_ARG_NONNULL(params)
+
#include <config.h>
#include "canonicalize.h"
diff --git a/tests/test-ptsname_r.c b/tests/test-ptsname_r.c
index 19e33ea..9e1471c 100644
--- a/tests/test-ptsname_r.c
+++ b/tests/test-ptsname_r.c
@@ -14,6 +14,11 @@
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>. */
+/* Don't use __attribute__ __nonnull__ in this compilation unit. Otherwise gcc
+ may "optimize" the null_ptr function, when its result gets passed to a
+ function that has an argument declared as _GL_ARG_NONNULL. */
+#define _GL_ARG_NONNULL(params)
+
#include <config.h>
#include <stdlib.h>
--
2.7.4
next prev parent reply other threads:[~2020-01-05 8:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-05 6:24 [PATCH] stdlib: avoid canonicalize_file_name contradiction Jim Meyering
2020-01-05 8:15 ` Bruno Haible [this message]
2020-01-05 16:41 ` Jim Meyering
2020-01-05 16:46 ` Jim Meyering
2020-01-05 20:46 ` Bruno Haible
2020-01-05 21:52 ` Jim Meyering
2020-01-05 22:57 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4223468.KeoCiBS5fI@omega \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=jim@meyering.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).