This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] __fpurge(3)
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.
I have no problems if you want an ifdef __rtems__. If you still want
it, please say so. With this modification, I'd say the patch is good to
go.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat