Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 3020

Summary: bad define of pid_t in signal.h
Product: [Retired] Red Hat Linux Reporter: vgough
Component: glibcAssignee: Cristian Gafton <gafton>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-07-28 05:51:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description vgough 1999-05-24 22:00:49 UTC
signal.h, from glibc-devel-2.1.1-6, has this around line 60:

#if defined __USE_XOPEN && !defined pid_t
typedef __pid_t pid_t;
# define pid_t pid_t
#endif  /* Unix98 */

The "#define pid_t pid_t" causes an error "macro or
'#include' recursion too deep" when something tries to use
it (apparently with USE_XOPEN) is defined.  I noticed this
when trying to build CFS (cryptographic file system).

Doing a grep for "define pid_t pid_t" shows that it also
happens in termios.h and unistd.h...

Comment 1 vgough 1999-05-24 22:10:59 UTC
More things like this cause CFS compilation to break.  I found more
recursive pid_t defines in sys/stat.h , sys/types.h, and sys/wait.h.

And, there is a similar problem with ssize_t, in unistd.h and

This seems to happen all over the header files with various types.  Is
this a glibc header problem or a compiler problem?  Seems like a
poorly thought out header problem even if they were assuming the
compiler wouldn't recusively interpret defines...

Comment 2 Cristian Gafton 1999-07-28 05:51:59 UTC
What are the compile flags used by those programs? ANSI C certainly
does not forbid
	#define foo foo