Bug 130601 - identifier major macro expanded into gnu_dev_major
Summary: identifier major macro expanded into gnu_dev_major
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-22 16:52 UTC by Giuseppe Attardi
Modified: 2016-11-24 12:07 UTC (History)
6 users (show)

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


Attachments (Terms of Use)

Description Giuseppe Attardi 2004-08-22 16:52:49 UTC
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 14:02:53 UTC
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 14:32:59 UTC
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 14:52:44 UTC
#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 17:01:43 UTC
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 17:14:05 UTC
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 20:19:41 UTC
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.