Bug 2915

Summary:	sys/sysmacros.h included in sys/types.h - namespace pollution
Product:	[Retired] Red Hat Linux	Reporter:	vgough
Component:	glibc	Assignee:	Cristian Gafton <gafton>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.0	CC:	vgough
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-07-09 02:14:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.

regards,
Val

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.