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


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.

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.

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