This is the mail archive of the
mailing list for the newlib project.
Re: unistd.h ifdefs on OS
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: newlib at sourceware dot org
- Date: Fri, 22 Nov 2013 19:55:34 -0500 (EST)
- Subject: Re: unistd.h ifdefs on OS
- Authentication-results: sourceware.org; auth=none
- References: <528FC48F dot 7060308 at oarcorp dot com>
Newlib started out C90 compliant with some Unix/glibc extensions. Cygwin used newlib
as its base and wanted to support additional SYSV/C99/POSIX functions that were not supported in the newlib base.
They added conditionals to protect the name space and eventually RTEMS did the same. The conditionals
made it obvious that shared newlib didn't implement those interfaces and also removed the need to
define additional user-name-space types in types.h and _types.h.
unistd.h is a bit of a problem. It was part of early newlib (1992) and defined a number of the unix extensions
I mentioned earlier. It's a mess at the moment as you are correct that some prototypes have been added
that are not supported anywhere in the base shared newlib (e.g. posix or unix or misc) and are not protected by
One option would be to drop all flags, but I think a way to do this right would be to use features.h flags rather than OS
flags to segregate things (except for non-std extensions) with a flag or flags to allow base newlib unix extensions.
-- Jeff J.
----- Original Message -----
From: "Joel Sherrill" <firstname.lastname@example.org>
Sent: Friday, November 22, 2013 3:54:39 PM
Subject: unistd.h ifdefs on OS
In looking at unistd.h for the next restrict patch,
I noticed blocks like this:
#if defined(__CYGWIN__) || defined(__rtems__)
int _EXFUN(setegid, (gid_t __gid ));
int _EXFUN(seteuid, (uid_t __uid ));
These are POSIX methods which are not specific to RTEMS
or Cygwin. We just happen to be two targets that support
In other cases, newlib prototypes methods with no concern
whether they are implemented or not.
I know this was done historically but is there any reason
non-OS specific POSIX methods like these should be wrapped
by OS specific conditionals?
I rather like the idea of having POSIX .h files with methods
for which an implementation may not have the body. It avoids
a lot of unnecessary and ugly conditionals.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985