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 - bad define of pid_t in signal.h
Summary: bad define of pid_t in signal.h
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-24 22:00 UTC by vgough
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-07-28 05:51:36 UTC


Attachments (Terms of Use)

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
sys/types.h.

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
syntax.


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