Project

General

Profile

Bug #1977

warning: __WORDSIZE not defined

Added by Patrick Welche almost 3 years ago. Updated 7 months ago.

Status:
Feedback wanted
Priority:
Low
Assignee:
-
Category:
build system
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Cosmetics to make the -Wundef warning go away:

In file included from /usr/src/local/gromacs/src/gromacs/fileio/tngio.cpp:42:0:
/usr/src/local/gromacs/src/external/tng_io/include/tng/tng_io.h:327:6: warning: "__WORDSIZE" is not defined [-Wundef] # if __WORDSIZE == 64

This is slightly moot as PRId64 and friends are defined for me in inttypes.h which isn't from the GNU C Library.

To make the warning go away, one could wrap the __WORDSIZE testing code in (untested)
#if !defined(PRId64) || !defined(PRI...

However, that whole block probably won't work anyway because:

My headers do not define __STDC_FORMAT_MACROS, so tng_io.h goes on to test another non-standard macro, __WORDSIZE. The irony seems to be that if __WORDSIZE is defined on your system, you probably are running Linux, and therefore have PRId64 and friends defined already.

It reminds me of autoconf's AC_CHECK_SIZEOF([int *]) - presumably there is some sort of cmake equivalent if you really want to provide a fallback?
Or just #error ifndef PRId64 to verify this isn't a problem for anyone.

History

#1 Updated by Patrick Welche almost 3 years ago

Had a quick look at:

http://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html

and LONG_BIT / WORD_BIT. e.g., for me:

#define LONG_BIT 64
#define WORD_BIT 32

might be a drop in replacement for __WORDSIZE

#2 Updated by Patrick Welche almost 3 years ago

Note change in logic || -> &&. Check this is what was actually meant...

Trivial portability fix attached.

#3 Updated by Mark Abraham almost 3 years ago

We can't do that change because TNG is a project that compiles in C, and the C99 spec requires that such format specifier macros are only defined if requested. Merely changing to use WORD_BIT could work, though.

Most of the market for this code branch should be Windows. (What is your case, Patrick?) If so, then TNG could instead use https://github.com/chemeris/msinttypes and the problem goes away.

#4 Updated by Mark Abraham almost 3 years ago

  • Target version set to 2016

#5 Updated by Mark Abraham almost 3 years ago

  • Status changed from New to Feedback wanted

#6 Updated by Mark Abraham over 2 years ago

  • Target version deleted (2016)

#7 Updated by Erik Lindahl over 1 year ago

For Gromacs-2019 (and hopefully the development branch soon after the upcoming 2018 release) we'll move TNG to C++, and then we'll fix this too.

#8 Updated by Mark Abraham about 1 year ago

  • Target version set to 2019

#9 Updated by Mark Abraham 7 months ago

  • Target version changed from 2019 to 2020

Not happening for 2019

#10 Updated by Patrick Welche 7 months ago

(I seem to be making mistakes these days so check...)

I just compiled 2018.3 successfully on the same (as in, 2 years of updates) system, and didn't see warnings. Looking back at this bug, I wonder why I hit those warnings, as the system did have /usr/include/inttypes.h. I am guessing that, incorrectly, USE_STD_INTTYPES_H wasn't set, and that after a34f8680173ed297635fbe360a62c972f1bd44dd it was.

Also available in: Atom PDF