Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: domain of msebor@gmail.com designates
 74.125.83.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=eAtXvaC91qA/nXCxILCNZ46MSjK7OOw26NNiMD1rw8dpkYuT7a/9NelvwVCrQ8Q+mW
         BhW31Q1jSUdxY61LzH5p+kS0/HL77tBSN5fb5Gcq1KEj1g0R7MLtR4UhJ3QoM7JbyKk3
         Zd4xaBDGELa3VG9Fosaa1rV8jv88RsagBt0Gk=
Message-ID: <4C28C458.5090101@gmail.com>
Date: Mon, 28 Jun 2010 09:48:40 -0600
From: Martin Sebor <msebor@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: dev@stdcxx.apache.org
CC: Wojciech Meyer <Wojciech.Meyer@arm.com>
Subject: Re: stdcxx and POSIX
References: <DEE44AFE682197449410588EB783A51403635A485A@BUNGLE.Emea.Arm.com>
In-Reply-To: <DEE44AFE682197449410588EB783A51403635A485A@BUNGLE.Emea.Arm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 06/28/2010 03:35 AM, Wojciech Meyer wrote:
> Hi,
>
> 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.

Probably not without some minor tweaks. Stdcxx has been ported to
z/OS (w/o the POSIX compatibility layer) some time ago without much
difficulty so porting it to another non-POSIX platform shouldn't be
too hard. Off the top of my head, file.cpp, memattr.cpp, mman.cpp,
and once.cpp are the files that might need some work. memattr.cpp
isn't really being used by the library so providing an empty body
for the __rw_memattr() function for your platform should be good
enough.

> 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:
> 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.
>
> and here:
>    #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
> but that does not to fix the problem at all.

IIRC, _RWSTD_NO_NATIVE_IO was put in place when porting stdcxx
to z/OS. It hasn't been tested since then (perhaps as far back
as 2006) so it may have bit rotten.

>
> 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:
> #include<iostream>
> int main() { return 0; }
>
> 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.

I see. It looks as though we need a switch to use stdin et al
instead of STDIN_FILENO etc. Let me see if I can find some time
to look into it this week and get back to you.

Martin

>
> Thanks.
> Wojciech
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.