swarm of bugs in gnulib wrt restrict

swarm of bugs in gnulib wrt restrict

[Ingo Schwarze]

Hello,

i'd like to give you a heads-up regarding a swarm of bugs in gnulib
related to the C99 "restrict" keyword.  I first sent this report
directly to Bruno Haible because, as far as i can see, he was the
last one to add a new bug to that swarm, in this commit:

commit 182afcba2635cbff91240656c7fb3742dd23ab6f
Author: Bruno Haible <bruno@clisp.org>
Date:   Sat Feb 22 20:57:30 2020 +0100

But Bruno requested that i send this to bug-gnulib@ instead because
he considered it potentially interesting for more people and because
he hoped for participation of more people who posess exxpertise with
respect to the "restrict" keyword.


Before the commit, testing for "restrict" functionality was already
broken, and using "#define restrict ..." for C++ code was already
wrong, too.

The above commit added the additional bug to the swarm
that gnulib/lib/stdio.in.h can no longer be used from C++ code
either, because it now stomps on the application namespace, too.

For details, see comment #5 in this ticket:

  https://savannah.gnu.org/bugs/index.php?59276

I'm not planning to draft patches to gnulib myself because the
complexity of gnulib is seriously excessive for my taste.  All the
same, i consider it fair to send a notification in case you want
to investigate the problem on your own, using the information
in the above GNU troff ticket.

Yours,
  Ingo


P.S.
We found this because a recent update of gnulib in the GNU troff project

  -Subproject commit dce8759f0f0236a860a3e68b63c5e99cc6f168f9
  +Subproject commit d60a35e94c4f5b8f09f15828242418f5073d46e7

broke compilation with GCC 4.2.1, i.e. the latest GPLv2 version of
GCC.  After detecting that, another user reported that the build
crashed even with "gcc (Gentoo 9.3.0-r1 p3) 9.3.0", while the
build still succeeded with clang.

Fortunately, the workaround on the groff side was easy - just adding
#include "config.h" to all files that #include <stdio.h>, even to
those that don't need it for their own purposes, but we were worried
that more might be broken in groff, so i had a closer look and found
that nothing more appears to be broken in groff, but that gnulib suffers
from the issues listed in the ticket cited above.

P.P.S.
Unrelated to the swarm of bugs discussed above, but i might mention
this as well while here, even though it is not a proper bug report
but merely a concern.  For some years, several operating systems
have now been discouraging or even outlawing %n in printf(3) for
security reasons.  Some do so by default with an option for the
application developer to re-enable it (e.g. MS Windows), some do
so unconditionally for %n in writeable memory (e.g. MacOS X), and
GNU/Linux appears to provide some hardening option to the effect.

If the operating system provides a secure printf(3) that forbids
%n in writeable memory, then gnulib mis-classifies that deliberate
decision as a defect and compiles vasnprintf.c, which unconditionally
re-enables %n in writeable memory behind the users back.  I consider
silently and agressively disabling security features of the
operating system very nasty misbehaviour and totally outside the
scope of a portability library.

The net effect is that the more modern a version of glibc is in
use, the more likely that gnulib will wrongly consider the native
printf(3) broken and replace it with its own, less secure version.
I got a report from a user who had that happen to him even on an
up-to-date Gentoo Linux system.

-- 
Ingo Schwarze             <schwarze@usta.de>
http://www.openbsd.org/   <schwarze@openbsd.org>
http://mandoc.bsd.lv/     <schwarze@mandoc.bsd.lv>

Re: swarm of bugs in gnulib wrt restrict

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

On 10/24/20 7:24 AM, Ingo Schwarze wrote:

>    https://savannah.gnu.org/bugs/index.php?59276

As I understand it, the problem here is that Gnulib-using C++ code can't use 
'restrict' as an identifier. This is worth documenting so I installed the 
attached patch. It's low priority to try to fix this, as it's a very minor 
restriction on Gnulib-using C++ code.

[-- Attachment #2: 0001-doc-mention-restrict-and-C.patch --]
[-- Type: text/x-patch, Size: 1532 bytes --]

From 7d0b18cc9b553d07e2f60d5315e39e4e82e60033 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 24 Oct 2020 13:35:17 -0700
Subject: [PATCH] =?UTF-8?q?doc:=20mention=20=E2=80=98restrict=E2=80=99=20a?=
 =?UTF-8?q?nd=20C++?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/gnulib-readme.texi (C99 features assumed): Document
that ‘restrict’ should be avoided in C++ code.
---
 ChangeLog              | 6 ++++++
 doc/gnulib-readme.texi | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 39257f6e2..8fa32e1ec 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2020-10-24  Paul Eggert  <eggert@cs.ucla.edu>
+
+	doc: mention ‘restrict’ and C++
+	* doc/gnulib-readme.texi (C99 features assumed): Document
+	that ‘restrict’ should be avoided in C++ code.
+
 2020-10-20  Bernhard Voelker  <mail@bernhard-voelker.de>
 
 	selinux-at, selinux-h: port to SELinux 3.1
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index 2ec11d554..beb0ca9b6 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -384,6 +384,8 @@ Variadic macros.
 @item
 The @code{restrict} qualifier, assuming
 @code{AC_REQUIRE([AC_C_RESTRICT])} is used.
+This qualifier is sometimes implemented via a macro, so C++ code that
+uses Gnulib should avoid using @code{restrict} as an identifier.
 
 @item
 Flexible array members (however, see the @code{flexmember} module).
-- 
2.25.1

Re: swarm of bugs in gnulib wrt restrict

[Bruno Haible]

Paul Eggert wrote:
> >    https://savannah.gnu.org/bugs/index.php?59276
> 
> As I understand it, the problem here is that Gnulib-using C++ code can't use 
> 'restrict' as an identifier.

No, that is not even the problem: The groff source code does not use 'restrict'
as an identifier, nowhere.

When I look at this recent commit of Ingo Schwarze [1], it seems the problem
was an incorrect use of Gnulib: Some source .cpp files did not have
#include <config.h>
as their first non-comment line. But this is a documented requirement for
packages that use Gnulib [2], since 2007.

Bruno

[1] https://git.savannah.gnu.org/gitweb/?p=groff.git;a=commitdiff;h=fe121eeacd53c96105f23209b2c205f436f97359
[2] https://www.gnu.org/software/gnulib/manual/html_node/Source-changes.html