Resolved: (STDCXX-1049) _RWSTD_NO_NATIVE_IO doesn't disable native I/O

> _RWSTD_NO_NATIVE_IO doesn't disable native I/O
> ----------------------------------------------
>
>                 Key: STDCXX-1049
>                 URL: https://issues.apache.org/jira/browse/STDCXX-1049
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: 27. Input/Output
>    Affects Versions: 4.2.1
>         Environment: non-POSIX
>            Reporter: Martin Sebor
>            Assignee: Martin Sebor
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> Quoting from the thread [Re: stdcxx and POSIX|http://mail-archives.apache.org/mod_mbox/stdcxx-dev/201006.mbox/%3CDEE44AFE682197449410588EB783A51403635A485A@...%3E]
> {quote}
> We are trying to use stdcxx library on a environment where POSIX
> environment is not available (and it is not a win32 platform), as
> a continuation of RoguWave library.  We would like to know if
> stdcxx supports it. We have found some occurrences of POSIX
> headers and symbols in {{file.cpp}} and {{iostream.cpp}}.  Although
> run-time behavior for iostreams can be changed by passing
> unofficial extension to openmode {{\_RWSTD_IOS_STDIO}}, but the POSIX
> symbols are still present, so the compilation will fail.  There is
> {{_RWSTD_NO_NATIVE_IO}} as the {{README}} file says:
> {code}
> o _RWSTD_NO_NATIVE_IO
> [lib, over]
>  #defined  to force  file streams  to use  the facilities  of libc
>  stdio as opposed to the POSIX I/O interface.
> {code}
> and here:
> {code}
>   #ifndef _RWSTD_NO_NATIVE_IO
>   # define _RWSTD_INVALID_FILE     -1
>   # define _RWSTD_INVALID_OPENMODE -1
>   #else
>   # define _RWSTD_INVALID_FILE      (FILE*)0
>   # define _RWSTD_INVALID_OPENMODE  0
>   #endif // _RWSTD_NO_NATIVE_IO
> {code}
> but that does not to fix the problem at all.
> On other side, the initialization routine ({{iostream.cpp}}) uses POSIX
> file descriptors and posix calls for std console streams ({{cout}},
> {{cin}}, {{cerr}} objects and wchar equivalents), in this case there is no
> other way than patching library to replace it with {{stdio.h}} functionality.
> To reproduce the problem, on the system where POSIX is not present:
> {code}
> #include <iostream>
> int main() { return 0; }
> {code}
> Will fail, because we could not compile it, even if we compiled it
> excluding files that use POSIX we will get linking errors.  Is
> there any chance of solving it in your upstream? We know about the
> status of Apache STL.
> {quote}