This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 05/18/2011 01:59 AM, Ralf Corsepius wrote:Good to know and not much of a problem (c.f. below).On 05/18/2011 09:47 AM, Yaakov (Cygwin/X) wrote:On Wed, May 18, 2011 at 02:16, Ralf Corsepius wrote:Cygwin's homepage makes it pretty clear: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__).
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,
Well, things actually are simple: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).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |