Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.161.54 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=T/An/8PuoR08zqZzm57HCkr5tOrYBPwlXeThm0TddQnXCFii0mhnc8wq1irdms5aSB
         PJcv7nOImouPmEGHzq9iU0KCOAzI9uaE/pXcV0YmyrJZjqHKm9xgpIw5jJ+mjTXcXMJF
         I1vVFqpjczgBXKRAI/g6ebpPzgEsxz3RvV+lU=
Message-ID: <4C593478.3000005@gmail.com>
Date: Wed, 04 Aug 2010 03:35:52 -0600
From: Martin Sebor <msebor@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc11 Thunderbird/3.0.3
MIME-Version: 1.0
To: Wojciech Meyer <Wojciech.Meyer@arm.com>
CC: dev@stdcxx.apache.org
Subject: Re: stdcxx and POSIX
References: <DEE44AFE682197449410588EB783A51403635A485A@BUNGLE.Emea.Arm.com>
 <4C28C458.5090101@gmail.com>
 <DEE44AFE682197449410588EB783A51403635A4A2B@BUNGLE.Emea.Arm.com>
 <4C3116D6.8060205@gmail.com>
 <DEE44AFE682197449410588EB783A51403636D2985@BUNGLE.Emea.Arm.com>
 <4C3C8167.8060209@gmail.com>
 <DEE44AFE682197449410588EB783A51403BF415DA6@BUNGLE.Emea.Arm.com>
 <4C486926.2040103@gmail.com>
 <DEE44AFE682197449410588EB783A51403BF415EA6@BUNGLE.Emea.Arm.com>
 <4C53582C.9050800@gmail.com> <000101cb3241$fe2ff550$fa8fdff0$@Meyer@arm.com>
In-Reply-To: <000101cb3241$fe2ff550$fa8fdff0$@Meyer@arm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/02/2010 06:55 AM, Wojciech Meyer wrote:
> Martin,
>
> I've checked your patches in our environment today, and after a small
> adjustment I got it to work.  I still have not tested it under Windows,
> as I would need to setup either Visual Studio or Mingw/MSYS environment,
> that is said I am on vm only (but I will do this soon). I am attaching
> the corrected patch. The other one is OK.  The good thing to do would be
> to send all diffs from your sandbox to me once you can, probably after
> holidays (mine will end up with 22nd of Aug), so I can apply it here and
> test it on Windows too, before you commit.

Will do!

Thanks
Martin

>
> Cheers;
> Wojciech
>
> -----Original Message-----
> From: Wojciech Meyer [mailto:Wojciech.Meyer@arm.com]
> Sent: 02 August 2010 09:25
> To: 'Martin Sebor'
> Cc: dev@stdcxx.apache.org
> Subject: RE: stdcxx and POSIX
>
>> Wojciech,
>
>> I started applying the patch hoping to be able to commit it
>> before I leave for my trip tomorrow but I'm not going to be
>> able to make it.
>
> No problem, I will be off on holiday starting next week, for two weeks
> time. And it is not a blocker here.
>
>> I think most (but not all) uses of the _RWSTD_NO_NATIVE_IO
>> macro should be replaced with one that checks for POSIX or
>> UNIX features. Unfortunately, it's not as easy as replacing
>> those references with something like __unix__ because that
>> would break (or disable the functionality on) Windows.
>
> There are a couple of things:
> - it could be a user defined Makefile variable (e.g WITHOUT_POSIX). (if
>    you are up to a patch that exactly does it, let me know)
> - it will not break only windows build but all of the non Unix builds as
>    well (which is the case here).
>
>> Attached are a couple of untested patches to illustrate
>> what I have in mind. I don't have a Windows box to test my
>> changes on so if you do and have the time to work on it and
>> test it there that'd be great. Otherwise it'll need to wait
>> until I get back at the end of August.
>
> Thanks for it, fortunately I am able to to test them in our environment
> (and I will try to do it on vm windows too)
>
>> Martin
>
> Wojciech
>
> On 07/22/2010 11:11 AM, Wojciech Meyer wrote:
>> Hi Martin,
>>
>> Thanks for the update!
>>
>> I will svn-up the sandbox sometime next week.
>>
>> Cheers;
>> Wojciech
>>
>> PS: It's worth to know others that it's been solved so I CC back to ML.
>>
>>
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com]
>> Sent: 22 July 2010 16:52
>> To: Wojciech Meyer
>> Subject: Re: stdcxx and POSIX
>>
>> On 07/22/2010 07:14 AM, Wojciech Meyer wrote:
>>> Hi Martin!
>>>
>>> I haven't got any response from you yet, is there any progress on
> reviewing it?
>>> Please let me know when you will be able.
>>> Thanks,
>>
>> Sorry (and thanks for the reminder). We had a fire drill over the
>> weekend due to a customer problem. The patch looks good. I think
>> I'll just use a different macro instead of _RWSTD_NO_NATIVE_IO
>> since we're using it guard all kinds of POSIX things, not just
>> I/O.
>>
>> I've added an issue and attached your patch to it:
>>      http://issues.apache.org/jira/browse/STDCXX-1050
>>
>> Let me test it and check it in this weekend.
>>
>> Martin
>>
>>>
>>> Wojciech
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Wojciech Meyer
>>> Sent: 15 July 2010 10:31
>>> To: 'Martin Sebor'
>>> Subject: RE: stdcxx and POSIX
>>>
>>>> In my patch I only focused on the iostream problem. A more complete
>>>> fix would be great -- I'll gladly take your patches!
>>>
>>> So here it goes! A complete patch for a non POSIX platforms.
>>>
>>> We have other small issues here, regarding running configuration files
>>> on models, I will update you on the mailing list soon!
>>>
>>> BTW: I've tested it with PH, and there no regressions.
>>>
>>> Thanks,
>>> Wojciech
>>>
>>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:msebor@gmail.com]
>>> Sent: 13 July 2010 16:08
>>> To: Wojciech Meyer
>>> Subject: Re: stdcxx and POSIX
>>>
>>> On 07/13/2010 08:12 AM, Wojciech Meyer wrote:
>>>> Hi Martin,
>>>>
>>>> I checked your latest changes and they had improved everything, but
>>>> unfortunately some POSIX problems still persisted. (it is not an easy
>>>> task to find a purely non POSIX and non win32 environment - I know)
>>>> However I've fixed them all on the stdcxx-4.2.x head. (if you accept any
>>>> downstream patches, I am willing to share it, once I got sorted it
>>>> here).
>>>
>>> In my patch I only focused on the iostream problem. A more complete
>>> fix would be great -- I'll gladly take your patches!
>>>
>>>>
>>>> One thing: the stdcxx-4.2.x head build on gcc is currently broken (it is
>>>> important because I would like to run tests before I send the changes),
>>>> on my machine on:
>>>
>>> I think this is a known problem. Probably STDCXX-512 or one of these:
>>>
>>>         http://tinyurl.com/28m5juc
>>>
>>> Martin
>>>
>>>>
>>>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
>>>> gcc (GCC) 4.4.4
>>>>
>>>> with following compilation errors:
>>>>
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
> instantiated from here
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional:90: error: no match
> for 'operator*' in '__x * __y'
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional: In member function
> 'typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
> std::divides<_TypeT>::operator()(const typename std::binary_function<_TypeT,
> _TypeT, _TypeT>::first_argument_type&, const typename
> std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
> [with _TypeT = UserClass]':
>>>> /work/svn/stdcxx/branches/4.2.x/include/algorithm:362:   instantiated
> from '_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
> _OutputIter, _BinaryOperation) [with _InputIter1 = UserClass*, _InputIter2 =
> const UserClass*, _OutputIter = UserClass*, _BinaryOperation =
> std::divides<UserClass>]'
>>>> /work/svn/stdcxx/branches/4.2.x/include/valarray:383:   instantiated
> from 'std::valarray<_TypeT>&     std::valarray<_TypeT>::operator/=(const
> std::valarray<_TypeT>&) [with _TypeT = UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:384:
> instantiated from 'void test_div_assign(const T*, const char*, const char*)
> [with T = UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:762:
> instantiated from 'void test_op_assign(const T*, const char*) [with T =
> UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
> instantiated from here
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional:103: error: no match
> for 'operator/' in '__x / __y'
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional: In member function
> 'typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
> std::plus<_TypeT>::operator()(const typename std::binary_function<_TypeT,
> _TypeT, _TypeT>::first_argument_type&, const typename
> std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
> [with _TypeT = UserClass]':
>>>> /work/svn/stdcxx/branches/4.2.x/include/algorithm:362:   instantiated
> from '_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
> _OutputIter, _BinaryOperation) [with _InputIter1 = UserClass*, _InputIter2 =
> const UserClass*, _OutputIter = UserClass*, _BinaryOperation =
> std::plus<UserClass>]'
>>>> /work/svn/stdcxx/branches/4.2.x/include/valarray:396:   instantiated
> from 'std::valarray<_TypeT>&     std::valarray<_TypeT>::operator+=(const
> std::valarray<_TypeT>&) [with _TypeT = UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:461:
> instantiated from 'void test_add_assign(const T*, const char*, const char*)
> [with T = UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:770:
> instantiated from 'void test_op_assign(const T*, const char*) [with T =
> UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
> instantiated from here
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional:64: error: no match
> for 'operator+' in '__x + __y'
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional: In member function
> 'typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
> std::minus<_TypeT>::operator()(const typename std::binary_function<_TypeT,
> _TypeT, _TypeT>::first_argument_type&, const typename
> std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
> [with _TypeT = UserClass]':
>>>> /work/svn/stdcxx/branches/4.2.x/include/algorithm:362:   instantiated
> from '_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
> _OutputIter, _BinaryOperation) [with _InputIter1 = UserClass*, _InputIter2 =
> const UserClass*, _OutputIter = UserClass*, _BinaryOperation =
> std::minus<UserClass>]'
>>>> /work/svn/stdcxx/branches/4.2.x/include/valarray:409:   instantiated
> from 'std::valarray<_TypeT>&     std::valarray<_TypeT>::operator-=(const
> std::valarray<_TypeT>&) [with _TypeT = UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:521:
> instantiated from 'void test_sub_assign(const T*, const char*, const char*)
> [with T = UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:774:
> instantiated from 'void test_op_assign(const T*, const char*) [with T =
> UserClass]'
>>>>
> /work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
> instantiated from here
>>>> /work/svn/stdcxx/branches/4.2.x/include/functional:77: error: no match
> for 'operator-' in '__x - __y'
>>>>
>>>> Thanks!
>>>>
>>>> Wojciech
>>>>
>>>> -----Original Message-----
>>>> From: Wojciech Meyer
>>>> Sent: 05 July 2010 11:19
>>>> To: 'Martin Sebor'
>>>> Subject: RE: stdcxx and POSIX
>>>>
>>>> Martin,
>>>>
>>>> Thanks your prompt patch!  I will try to get back to you ASAP on Jira&
>>>> dev mailing list, with the feedback (hopefully sometime this week).
>>>> There might be some way of sending something back to you (I hope), but
>>>> for that I cannot say when.  So please be patient, and once more thanks.
>>>>
>>>> Wojciech
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Martin Sebor [mailto:msebor@gmail.com]
>>>> Sent: 05 July 2010 00:19
>>>> To: Wojciech Meyer
>>>> Cc: dev@stdcxx.apache.org
>>>> Subject: Re: stdcxx and POSIX
>>>>
>>>> Wojciech,
>>>>
>>>> This patch fixes the problem for me. Please check it out
>>>> and let me know if it works for you:
>>>>
>>>>        http://svn.apache.org/viewcvs?view=rev&rev=960407
>>>>
>>>> If you continue to see problems with it (or any other part
>>>> of stdcxx) it would be best if you could open issues in Jira.
>>>> This one is being tracked here:
>>>>
>>>>        http://issues.apache.org/jira/browse/STDCXX-1049
>>>>
>>>> Feel free to add your comments to it (or reopen it).
>>>>
>>>> Let me know how the rest of your project goes!
>>>>
>>>> Martin
>>>>
>>>> On 06/28/2010 10:27 AM, Wojciech Meyer wrote:
>>>>> Hi Martin,
>>>>>
>>>>> Thank you for the quick reply.
>>>>>
>>>>>>> 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.
>>>>>
>>>>>> 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.
>>>>>
>>>>> I think it would be very nice if Stdcxx could handle out of the box non
>>>>> POSIX platforms, it is important especially in embedded world. I will
> not
>>>>> mention test and utilities, as this could be more problematic.
>>>>>
>>>>>>> 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.
>>>>>
>>>>> That would be great, then we could test on our environment and provide
>>>>> you some sort of immediate feedback about it.
>>>>>
>>>>>> Martin
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> -- 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.
>>>
>>>
>>> -- 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.
>>
>>
>> -- 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.
>