[bug #59276] [PATCH] #include "config.h" before <stdio.h>

[Ingo Schwarze]

Update of bug #59276 (project groff):

                  Status:               Need Info => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #5:

Fortunately, nothing more is broken here on the side of groff or its build
system.

First, note that "restrict" is a C99 keyword, but not a C++ keyword. 
Consequently, in C++, the string "restrict" is available as an identifier to
be used by the program (though i'm not saying that using "restrict" as an
identifier in a C++ program is a good idea; it is likely to cause
compatibility issues on some platforms).

The groff C++ files that i added #include "config.h" to use <stdio.h>, which
is valid in C++.  The system header /usr/include/stdio.h on most operating
systems typically use an implementation-specific keyword like "__restrict" or
"__restrict__" specifically such that these headers can be included in C++
programs without stomping on the "restrict" identifdier in the application
namespace.  So far, all is fine.

What *is* subtly broken is gnulib.  It is broken in the following way.  It
does not test availability separately for the C and C++ languages, but does
only one set of tests, and only with the C compiler, not with the C++
compiler.  It first tests whether a C99 program using "__restrict" (which is a
commonly supported compiler extension) can be compiled, and if that succeeds,
it adds "#define restrict __restrict" to "config.h".  That is WRONG for two
reasons:

1. Theoretically, a standard-conforming C99 compiler might (unwisely) use the
implementation-namespace keyword "__restrict" for *different* functionality. 
In that case, application programs correctly using the "restrict" keyword will
be miscompiled.

2. If a C++ program uses "restrict" as an identifier, that program will be
miscompiled.  With most compilers, compilation will simply fail because
"__restrict" can rarely be used at places where an identifier is valid.

Gnulib is also broken is so far as it uses the "restrict" keyword in its own
replacement version of <stdio.h>.  Strictly speaking, that makes the gnulib
<stdio.h> unusable for C++ code.  To be correct, it would instead have to use
a string from the reserved namespace like "__restrict" or "__restrict__".

For practical purposes, both gnulib bugs probably matter little for groff.  Ad
(2), groff does not (and should not) try to use "restrict" as an identifier. 
Ad (1), i doubt that groff intends to support any compilers using "__restrict"
for different purposes.

Consequently, i'm closing the ticket again.  If we want to pursue this issue
further, we should take it upstream to gnulib, but i doubt that anybody is
willing to deal with that repository of exceedingly convoluted code.

P.S.
Here is an example of a valid, but unwise C++ program:

 $ cat restrict.cpp                                             
int
main(void)
{
        int restrict;

        restrict = 42;
        return restrict;
}
 $ make restrict
c++ -O2 -pipe    -o restrict restrict.cpp 
 $ ./restrict
 $ echo $?
42

It is not valid C:

restrict_c.c:4:6: error: restrict requires a pointer or reference
        int restrict;
restrict_c.c:6:11: error: expected identifier or '('
        restrict = 42;
restrict_c.c:7:9: error: expected expression
        return restrict;


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59276>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/