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 <br...@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 <schwa...@usta.de> http://www.openbsd.org/ <schwa...@openbsd.org> http://mandoc.bsd.lv/ <schwa...@mandoc.bsd.lv>
