stdio_ext.h function implementations
Corinna Vinschen
vinschen@redhat.com
Wed Dec 10 09:40:00 GMT 2014
Hi Yaakov,
On Dec 9 14:58, Yaakov Selkowitz wrote:
> Currently, the bulk of the <stdio_ext.h> functions[1][2] are implemented as
> inline code, or macros on non-gcc-compatible toolchains. However, there are
> a few issues with that:
>
> * Header-only implementations result in false negatives from AC_CHECK_FUNC
> tests and the like. For instance, cpio FTBFS on Cygwin currently because it
> tries to implement a replacement for a "missing" __fpending which conflicts
> with the one already in <stdio_ext.h>.
>
> * The Solaris and Linux documentation indicates that at least some, if not
> all, of these functions are thread-safe. Does the current implementation
> suffice for that, or do these need to be real functions wrapped in
> _newlib_flockfile_{start,end} calls?
The implementation is sufficent for that.
> * Macro implementations of libc functions need to be undef'ed and backed by
> real functions with C++ (otherwise you get syntax errors in the ::func
> form). Are the inline implementations used by GCC safe for these purposes?
Apart from the fact that the header was broken (too many "inline", fixed
now), inline functions are safe. ::__fpending(stdin) is a valid expression.
> * No documentation is generated for these functions.
>
> In any case, for the first point alone, we need real code implementations of
> these functions. I am prepared to make a patch for this, but exactly how
> depends on the second and third points above.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20141210/b84f00da/attachment.sig>
More information about the Newlib
mailing list