[patch] Include some c99 functions in __STRICT_ANSI__ for cygwin c99.

[Jeff Johnston]

I think the better solution is to emulate glibc which uses the flag 
__USE_XOPEN2K to determine if fseeko and ftello are to be used.

So I made the following patch which sets the __USE_XOPEN2K flag for 
Cygwin and uses to check for fseeko, ftello when __STRICT_ANSI__ is set.

The remainder of the I/O functions in that chunk are included if C99.

A patch is attached.  Let me know if you have any concerns, otherwise 
I'll check it in.

-- Jeff J.

On 15/10/09 12:11 AM, Dave Korn wrote:
>
>      Hello Jeff and list,
>
> Refs: http://www.cygwin.com/ml/cygwin/2009-04/threads.html#00435
>        http://cygwin.com/ml/cygwin/2009-10/threads.html#00324
>        http://cygwin.com/ml/cygwin/2009-10/msg00406.html
>
>    We had a couple of complaints over on the Cygwin list about function
> prototypes not present when using --std=c99; this is of course to be expected
> since newlib's definition of _STRICT_ANSI_ is based as we all know on c90, and
> none of those functions were defined in the earlier ANSI standards.
>
>    On Cygwin, we'd like to be as Linux, POSIX and c99 compatible as we can,
> which is why this patch only changes the semantics of _STRICT_ANSI_ when
> __CYGWIN__.  If the c99 standard is in effect, then it includes all the
> functions that people have complained about missing: the {sn,v*}{print,scan}f
> family and f{seek,tell}o.
>
>    I've made this conditional on __CYGWIN__ so as not to produce any unexpected
> side-effects for any other users, but you might decide it makes as much sense
> to make this an unconditional change.
>
>    However, even in that case, a Cygwin-specific bit may be needed:
>
>    The new formatted i/o functions are part of c99, but the fseeko and ftello
> functions are not; they are only part of POSIX.  Since Linux/Glibc includes
> their declarations in _STRICT_ANSI_ (taking, if I've read the wording right,
> advantage of the leeway provided by the definition of the CX extension type
> annotation in the SUS to allow them to be regarded as extensions to the c99
> spec in this context, as described in the third reference above), and since
> Cygwin's goal is Linux emulation, it certainly makes sense to include them in
> _STRICT_ANSI_ for Cygwin.
>
>    Other platforms might only want the formatted i/o functions from the core
> c99 spec to be added to _STRICT_ANSI_, depending on their own stance toward
> POSIX compliance.  So even if it was desirable to make this change not
> conditional on __CYGWIN__, I think it might still make sense to keep this part
> of the change Cygwin-only.  Then again, there are also Linux newlib platforms;
> they'd probably like to have the definitions visible in c99 mode.
>
>    So, here's the patch, and I figured I'd leave it to you to decide what's the
> best form for the conditional to take.  Tested by building a winsup checkout
> before and after the change in separate objdirs, installing both into separate
> DESTDIRs, manually verifying the difference was in the second installed header
> and not the first, and that the warnings from the testcases posted to the
> threads referenced above were manifested when compiling with a -I option into
> the before DESTDIR/usr/include and not generated when compiling with a -I
> option pointing into the after DESTDIR/usr/include.
>
> newlib/ChangeLog:
>
> 	* libc/include/stdio.h: Include additional C99 formatted I/O
> 	functions and POSIX fseeko/ftello in _STRICT_ANSI_ for Cygwin
> 	when __STDC_VERSION__ indicates C99 or later standard in use.
>
>    What do you think?
>
>      cheers,
>        DaveK
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin.patch
Type: text/x-patch
Size: 1828 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20091016/7728c6dd/attachment.bin>