This is the mail archive of the
mailing list for the newlib project.
Re: unistd.h ifdefs on OS
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jeff Johnston <jjohnstn at redhat dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Sat, 23 Nov 2013 08:32:11 -0600
- Subject: Re: unistd.h ifdefs on OS
- Authentication-results: sourceware.org; auth=none
- References: <528FC48F dot 7060308 at oarcorp dot com> <1046365378 dot 30636875 dot 1385168134117 dot JavaMail dot root at redhat dot com>
On 11/22/2013 6:55 PM, Jeff Johnston wrote:
> 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.
Yeah. We started using newlib in the 1993/4 time frame.
When we added prototypes or support for methods, we tended
to follow the Cygwin ifdefs and just pile on. I never
realized that the rationale was whether or not a generic
functional body was in newlib. And this shows in other
places where the OS ifdefs really only protect additions
> 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
> any flags.
That's what I spotted. From RTEMS perspective, we support
POSIX Profile 52 which is basically single process, multi-threaded.
Newlib owns some of the .h files which have the prototypes. If
the prototype was in POSIX, we felt no obligation to wrap it with
an __rtems__ unless we were piling on an existing one.
The mix of C Library and POSIX .h files and methods within
technically from both standards within a single .h, creates
> 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.
I would be in agreement if by feature flags, you mean the
strict ANSI, GNU, XOPEN, POSIX, and BSD ones. I would hate
to see every prototype wrapped with "HAVE_XXX" define.
This would make the .h files more standards oriented and
less "what does target X support?" oriented.
FWIW Google Code-In goes on until Jan 6. If there is work
we want done on newlib which can be done in small units
of work and well defined, RTEMS would be happy to add the
tasks. If a couple of people from newlib would help mentor
them, it would be a huge help. I am mentoring all the newlib
tasks we have right now.
I was already thinking of a set of tasks where each was
something like review existing XXX.h against POSIX, identify
any missing methods, and add the prototypes.
> -- Jeff J.
> ----- Original Message -----
> From: "Joel Sherrill" <firstname.lastname@example.org>
> To: email@example.com
> 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.
> Comments? Thoughts?
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