Description of problem: identifier major macro expanded into gnu_dev_major Version-Release number of selected component (if applicable): gcc 3.3.2 How reproducible: easely Steps to Reproduce: 1. compile this program: #include <fstream> struct Header { int major; Header(int mj) : major(mj) { } }; Actual results: foo.cc: In constructor `Header::Header(int)': foo.cc:7: error: class `Header' does not have any field named `gnu_dev_major' Expected results: success Additional info:
The problem is that g++ adds -D_GNU_SOURCE and major() is a macro in _GNU_SOURCE (or _BSD_SOURCE or when no feature set is requested). You can always #undef major after including headers.
You must be kidding. If g++ wants to add some define, it should at least use underscore in the defined name, to avoid clobbering user names. major is not a reserved keyword in C or C++. -- Giuseppe Attardi
#include <sys/types.h> is supposed to define major(), minor() and makedev() macros unless pure ISO C feature set (e.g. with -ansi, -std=c89, -std=c99 or -D_ISOC99_SOURCE) is selected. Now, <fstream> (via. <cstdlib>/<stdlib.h>) includes <sys/types.h> and libstdc++-v3 for its own purposes requests GNU feature set. IMHO including <sys/types.h> in a C++ program (or <stdlib.h>) should still define major() macro, but already <cstdlib> should not.
makedev(), major() and minor() should be functions, not macros. It looks they were introduced in __GNUC__ >= 2 in sys/sysmacros.h for backward compatibility. It is not a good idea. Fiddling with macros is dangerous since it pollutes user name space.
There will be no change. If some code does not like the macros, add #undefs after the appropriate #include. The macros are part of the API and removing them only causes problems.
Upstream glibc has reconsidered this bug. In some future release, glibc's <sys/types.h> will not include <sys/sysmacros.h> anymore. As of 2.25, it still does, but you get deprecation warnings if you use the macros without including <sys/sysmacros.h>. We have not decided exactly which future release will finally remove the #include; to help us decide, please send reports of software that trips the deprecation warnings to libc-alpha. (We have just begun development of 2.25. 2.24, which will be released in a few days, does not change anything wrt this bug.)