csharpexec.c causes intmax_t from config.h to be redefined.

[John Malmberg]

On VMS, the config.h file is generated to "#define intmax_t long long".

The csharpexec.c module includes config.h and then includes some header
files that redefine intmax_t.

After it does that, it #includes "classpath.c" which then includes
config.h again.

This causes the original definition to be restored, and the VMS C
compiler issues a diagnostic about it.

#define intmax_t long long
.................^
%CC-W-MACROREDEF, The redefinition of the macro "intmax_t" conflicts
with a current definition because the replacement lists differ. The
redefinition is now in effect.

Is this an expected behavior?

Regards,
-John

[Bruno Haible]

Post by John Malmberg
On VMS, the config.h file is generated to "#define intmax_t long long".
The csharpexec.c module includes config.h and then includes some header
files that redefine intmax_t.
After it does that, it #includes "classpath.c" which then includes
config.h again.
This causes the original definition to be restored, and the VMS C
compiler issues a diagnostic about it.
#define intmax_t long long
.................^
%CC-W-MACROREDEF, The redefinition of the macro "intmax_t" conflicts
with a current definition because the replacement lists differ. The
redefinition is now in effect.

This is only a warning, and you can ignore it. Better compilers produce
a diagnostic only for redefinitions with a _different_ expansion.

But anyway, it's easy to make sure config.h is only included once, in
this case:


2017-06-19 Bruno Haible <***@clisp.org>

classpath: Avoid including config.h twice, as it produces warnings.
Reported by John E. Malmberg <***@gmail.com>.
* lib/classpath.h: Conditionalize the include of config.h.

diff --git a/lib/classpath.c b/lib/classpath.c
index e56f23f..c7868f6 100644
--- a/lib/classpath.c
+++ b/lib/classpath.c
@@ -15,7 +15,11 @@
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */

-#include <config.h>
+/* If CLASSPATHVAR is defined, this file is being #included, and config.h is
+ therefore already included. */
+#if !defined CLASSPATHVAR
+# include <config.h>
+#endif

/* Specification. */
#include "classpath.h"

[John Malmberg]

Post by Bruno Haible

Post by John Malmberg
On VMS, the config.h file is generated to "#define intmax_t long long".
The csharpexec.c module includes config.h and then includes some header
files that redefine intmax_t.
After it does that, it #includes "classpath.c" which then includes
config.h again.
This causes the original definition to be restored, and the VMS C
compiler issues a diagnostic about it.
#define intmax_t long long
.................^
%CC-W-MACROREDEF, The redefinition of the macro "intmax_t" conflicts
with a current definition because the replacement lists differ. The
redefinition is now in effect.

This is only a warning, and you can ignore it. Better compilers produce
a diagnostic only for redefinitions with a _different_ expansion.

The redefinition does have a different expansion:

I can reproduce the diagnostic by feeding the same code sequence to gcc.

***@solar:$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

***@solar:$ cat test.c
#define intmax_t long long
typedef long long int gl_intmax_t;
#undef intmax_t
#define intmax_t gl_intmax_t
#define intmax_t long long

***@solar:$ gcc -c test.c
test.c:5:0: warning: "intmax_t" redefined [enabled by default]
#define intmax_t long long
^
test.c:4:0: note: this is the location of the previous definition
#define intmax_t gl_intmax_t
^

Regards,
-John