On 05/18/2011 01:45 PM, Eric Blake wrote:
On 05/18/2011 01:59 AM, Ralf Corsepius wrote:
On 05/18/2011 09:47 AM, Yaakov (Cygwin/X) wrote:
On Wed, May 18, 2011 at 02:16, Ralf Corsepius wrote:
Generally speaking, I am opposed to furtherly extending newlib with
non-standardized functions like these.
I don't know what others (esp. Cygwin) think about such kind of
extensions,
but I'd like to see "not implemented" for RTEMS
(i.e. at minimum #ifndef __rtems__).
Cygwin's homepage makes it pretty clear:
a Linux API layer providing substantial Linux API functionality.
First, stdio/fpurge.c is ELIX_LEVEL_4. Secondly, why should
__fpurge(3) be any different than fpurge(3)?
History - We don't use neither and will likely want to get rid of
fpurge, too.
Conversely, I've got plans for getting fpurge(3) added to the next
revision of POSIX,
Good to know and not much of a problem (c.f. below).
I can understand your reluctance to have fpurge(3) until it is
standardized (even though newlib _already_ has it); but I can't
understand your resistance about __fpurge (which is in the
implementation namespace, and therefore is explicitly permitted by the
standard).
Well, things actually are simple:
* RTEMS is trying to be POSIX compliant and tries hard to avoid any
non-standardized extensions independently of their origin.
* RTEMS is targetting embedded systems, which also means we try to
keep it lean.