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>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Fri, 29 Nov 2013 18:17:09 -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> <5290BC6B dot 1050005 at oarcorp dot com> <1492185295 dot 33693136 dot 1385769160496 dot JavaMail dot root at redhat dot com>
On 11/29/2013 5:52 PM, Jeff Johnston wrote:
> ----- Original Message -----
>> From: "Joel Sherrill" <firstname.lastname@example.org>
>> To: "Jeff Johnston" <email@example.com>, firstname.lastname@example.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.
That might be a great first cut at it.
Would it account for cases like RTEMS where we have
our own implementations of methods that are in the tree?
We use the newlib prototype but not the source code.
But I am afraid that there are also cases like around the
group/process Id methods in unistd.h where magic is
>> 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 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.
It would also be a very picky one involving autotools which probably
is enough reason to avoid it for high school students.
>> 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?
Hadn't thought that far. If you are OK with
prototypes being added for missing POSIX 2013
methods in existing newlib .h files, then we
can add that as a task.
We just need a goal for the .h files. The students
we have had so far could easily handle this. If the
method needs a "_XXX_VISBLE" wrapper, we probably
should figure that out during the review cycle on
>>> -- Jeff J.
>>> ----- Original Message -----
>>> From: "Joel Sherrill" <email@example.com>
>>> To: 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.
>>> 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
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