Bug 130601 - identifier major macro expanded into gnu_dev_major
identifier major macro expanded into gnu_dev_major
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-22 12:52 EDT by Giuseppe Attardi
Modified: 2016-11-24 07:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-30 13:14:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Giuseppe Attardi 2004-08-22 12:52:49 EDT
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:
Comment 1 Jakub Jelinek 2004-08-30 10:02:53 EDT
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.
Comment 2 Giuseppe Attardi 2004-08-30 10:32:59 EDT
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
Comment 3 Jakub Jelinek 2004-08-30 10:52:44 EDT
#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.
Comment 4 Giuseppe Attardi 2004-08-30 13:01:43 EDT
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.
Comment 5 Ulrich Drepper 2004-08-30 13:14:05 EDT
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.
Comment 6 Zack Weinberg 2016-08-03 16:19:41 EDT
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.)

Note You need to log in before you can comment on or make changes to this bug.