Re: stdio_ext.h function implementations

[Corinna Vinschen <vinschen at redhat dot com>]

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

Attachment: pgpy3hpPLZvrg.pgp
Description: PGP signature