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: errno.h: ESTRPIPE


Ralf Corsepius wrote:
Christopher Faylor wrote:
On Mon, Mar 16, 2009 at 08:29:26AM +0100, Ralf Corsepius wrote:
newlib should stay with well established standards and not be polluted
with underdocumented, proprietary extensions.

Do you have any other irrational prejudices you'd like to share with us?
No, simply point me to an official (POSIX, IEEE, ANSII or similar) standard documenting ESTRPIPE.

Ralf

Hi Ralf,

According to Posix Section 2.4 states:

"Implementations may support additional errors not listed in this clause, but shall not generate a different error number from one required by this part of ISO/IEC 9945 for an error condition described in this part of ISO/IEC 9945...."

Similarly under SUSV:

"Additional implementation-dependent error numbers may be defined in <errno.h>"

Finally, glibc contains a number of errno extensions and it includes ESTRPIPE. Newlib often adopts glibc extensions as requested in the interest of making it easier to port code to newlib.

That said, if RTEMS absolutely doesn't want any of these extensions there are two alternatives. 1. Simply write a sys/errno.h file with only standard-provided errno values. If only standard-provided errnos plus RTEMS extensions are to be supported, this makes the most sense as you don't really require a common file and it will likely rarely require maintenance. 2. Add flag checks to sys/errno.h that segregate the extensions and only remove them if the flag is defined (by default all are provided). For example, __NO_ERRNO_EXTENSIONS__.

Seem reasonable?

-- Jeff J.


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