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/29/2013 5:52 PM, Jeff Johnston wrote:
> ----- 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.

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
still needed.

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

OK.

> 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.
>>b
> 
> 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
this list.


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



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