This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: unistd.h ifdefs on OS
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: newlib at sourceware dot org
- Date: Fri, 29 Nov 2013 18:52:40 -0500 (EST)
- 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> <5290BC6B dot 1050005 at oarcorp dot com>
----- Original Message -----
> From: "Joel Sherrill" <joel.sherrill@oarcorp.com>
> To: "Jeff Johnston" <jjohnstn@redhat.com>, newlib@sourceware.org
> Sent: Saturday, November 23, 2013 9:32:11 AM
> Subject: Re: unistd.h ifdefs on OS
>
> 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
> to standards.
>
> > 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
> this situation.
>
> > 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.
>
Sorry, to answer this so late, but yes, that is what I meant.
I could see adding a few other flags to match the various optional directories
we supply (e.g. misc, posix, unix). For example, something like
#if defined(USE_POSIX) | defined(NEWLIB_UNIX_DIR_EXT)
By default, we could turn the NEWLIB extension flags all on in sys/config.h
and let platforms #undef them if they wish to match the current behaviour.
> This would make the .h files more standards oriented and
> less "what does target X support?" oriented.
>
Agreed.
> 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 don't think there is enough time for me to mentor a proper rework of the headers. I'm off around Dec 17th or so until
January and I have a number of work items to do before then.
There is an open issue with make info creating the info docs in the source dirs. That
would be a small task to complete, but perhaps not interesting enough.
> 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.
>
Were you thinking of having them put these new routines under a flag to start with or would you see that as
a task later down the line?
> --joel
>
> > -- Jeff J.
> >
> > ----- Original Message -----
> > From: "Joel Sherrill" <joel.sherrill@oarcorp.com>
> > To: newlib@sourceware.org
> > Sent: Friday, November 22, 2013 3:54:39 PM
> > Subject: unistd.h ifdefs on OS
> >
> > Hi
> >
> > 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 ));
> > #endif
> >
> > These are POSIX methods which are not specific to RTEMS
> > or Cygwin. We just happen to be two targets that support
> > them.
> >
> > 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
>