[PATCH] __fpurge(3)

[Ralf Corsepius]

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.

Ralf