[PATCH] __fpurge(3)

[Ralf Corsepius]

On 05/19/2011 07:59 AM, Corinna Vinschen wrote:
> On May 18 14:19, Ralf Corsepius wrote:
>> 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.
>
> Ok, but the latter shouldn't be much of a problem given ELIX_LEVEL_4
> and a size of about 8 to 16 bytes for the __fpurge function.
On a more general scope, the problem with such proprietary functions 
like __fpurge is it is hard to get rid of them once they are spread.

That said, I consider all code using __fpurge to be of low quality and 
to be poorly designed ("Guys, you are writing non-portable code).

In this light, I'd actually recomment newlib not to adopt __fpurge.

> I have no problems if you want an ifdef __rtems__.  If you still want
> it, please say so.
Please do so  (#ifndef __rtems__ it).

>  With this modification, I'd say the patch is good to
> go.

Ralf