[PATCH] __fpurge(3)

[Eric Blake]

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, as it is extremely useful for things like
implementing a working fflush(3) on platforms where fflush fails to
reset seekable input files.  Even glibc was broken in this regards until
just this month; newlib was fixed a couple years ago (at the same time
that I added fpurge to newlib).

The gnulib project uses fpurge functionality (whether spelled fpurge
with a return type of int or spelled __fpurge with a return type of
void) rather heavily, which means a lot of GNU utilities require it (off
the top of my head, at least: cp, mv, rm, m4, find, tar, ...).

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).

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20110518/025c5050/attachment.sig>