stdio_ext.h function implementations

Corinna Vinschen vinschen@redhat.com
Thu Dec 11 09:20:00 GMT 2014


Hi Yaakov,

On Dec 10 23:36, Yaakov Selkowitz wrote:
> On 2014-12-10 03:40, Corinna Vinschen wrote:
> >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:
> >>[...]
> Patch attached; it also fixes the spelling of __fwritable() to match Solaris
> and glibc.

Thanks.

> Note that this code will only be pulled in by (1) AC_CHECK_FUNC configure
> tests or the like, (2) a non-__GNUC__-defining C++ compiler (IOW *not* g++,
> clang++, or icpc, nor *any* _C_ compiler), or (3) dlopen()ing these
> functions from a shared libc (e.g. Cygwin).  In all other cases, the
> inlines/macros in <stdio_ext.h> will be used. Therefore, I see little loss
> in providing a single .c file for these.
> 
> These are #ifndef __rtems__ because they have chosen not to support
> <stdio_ext.h> at all.
> 
> The functions call _newlib_flockfile_{start,end} even though the macros do
> not, to match the behaviour of clearerr() and feof().

Please remove them.  Keep the functions equivalent to the inline/macro
implementations.  All these functions only read a single flag value.
They don't need locking.

> +/* this function was previously misspelled */
> +#define __fwriteable(__fp) __fwritable(__fp)
> +

Keeping the misspelled macro shouldn't be necessary.  Please remove
it for the time being.

With these changes ok to check in.


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/20141211/d688e2e5/attachment.sig>


More information about the Newlib mailing list