This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unistd.h ifdefs on OS


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]