Bug 2915 - sys/sysmacros.h included in sys/types.h - namespace pollution
Summary: sys/sysmacros.h included in sys/types.h - namespace pollution
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-05-18 19:09 UTC by vgough
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-07-09 02:14:40 UTC

Attachments (Terms of Use)

Description vgough 1999-05-18 19:09:11 UTC
sys/types.h includes sys/sysmacros.h which then defines
major() and minor() macros.  Those macros make it impossible
to use variables or functions calls major or minor almost
everywhere because sys/types.h gets included in all sorts
of files and propogates around.

Other systems that I use (like Irix) also have
sys/sysmacros.h which define the same things, but they
do not include it in types.h.

This namespace pollution causes breakage in third party
libraries such at MTL (Math Template Library) that use
those names for internal variables and have nothing to do
with system devices or major/minor numbers.

This isn't a RedHat problem (other then that it first
appears in 6.0), but it's a glibc2.1 problem and I don't
know where to report these kinds of things for glibc2.1.


Comment 1 Derek Tattersall 1999-05-19 15:04:59 UTC
sysmacros.h is only included by types.h if __USE_BSD is defined.  Are
you explicitly defineing BSD compatability?

Comment 2 vgough 1999-05-24 21:53:59 UTC
USE_BSD gets defined in features.h when BSD_SOURCE is defined - which
is defined when GNU_SOURCE is defined.  I can't figure out where/how
GNU_SOURCE is being defined for my app...

Comment 3 Cristian Gafton 1999-07-09 02:14:59 UTC
You can include the features.h header as the first header, then
#undefine __USE_BSD and include the rest of teh headers.

The normal thing to do will be to test #ifdef major before using it
though. Those are standard BSD defines, so any library stepping on
that territory will be badly broken at least on BSD.

Anyway, there isn't much we can do to take care of this problem, so I
am closing the bug.

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