You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@epam.com> on 2007/08/28 15:09:25 UTC
[PATCH] STDCXX-77
Attached is a patch to make operator new on MSVC conforming to the C++
Standard.
ChangeLog:
* _config-msvcrt.h: #undefine _RWSTD_NO_NEW_THROWS and
_RWSTD_NO_NEW_OFLOW_SAFE macros if they're #defined.
* memory.cpp (__rw_new_handler_imp): Throw std::bad_alloc() if no user
handler installed.
(set_new_handler): Don't invoke _set_new_handler().
* new_supp.cpp: New file with helper object to make operator new
conforming to the C++ Standard
Farid.
Re: [PATCH] STDCXX-541
Posted by Martin Sebor <se...@roguewave.com>.
Liviu Nicoara wrote:
> I am attaching a tentative patch for review, in relation with STDCXX-541
> (https://issues.apache.org/jira/browse/STDCXX-541). Testing showed it
> solves the test case failure and adds no extra failures in the stdcxx
> strings test suite. This solves quite a few of related failures in
> strings in downstream products.
The patch looks good to me. Go ahead and commit it whenever you're
ready. Thanks!
>
> ChangeLog:
> * rw/_traits.h: added cast to unsigned char
Please make sure to follow the expected Change Log format. Here's
an example of a good one :)
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg00464.html
Martin
[PATCH] STDCXX-541
Posted by Liviu Nicoara <li...@roguewave.com>.
I am attaching a tentative patch for review, in relation with STDCXX-541
(https://issues.apache.org/jira/browse/STDCXX-541). Testing showed it
solves the test case failure and adds no extra failures in the stdcxx
strings test suite. This solves quite a few of related failures in
strings in downstream products.
ChangeLog:
* rw/_traits.h: added cast to unsigned char
RE: [PATCH] STDCXX-77
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, August 28, 2007 10:29 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] STDCXX-77
>
> Farid Zaripov wrote:
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin
> >> Sebor
> >> Sent: Tuesday, August 28, 2007 7:11 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: [PATCH] STDCXX-77
> >>
> >> I have one concern with the introduction of dynamic initialization
> >> and the pragma into the library. First, our
> >> (undocumented) design goal is to avoid requiring dynamic
> >> initialization in the library.
> >> I.e., there should be no code in the library that runs at startup.
> >> The rationale for it is efficiency and avoiding user code
> issues due
> >> to initialization dependencies. Since other libraries may use the
> >> same pragma, they will be subject to initialization
> dependencies that
> >> we try to avoid.
> >>
> >> Unless there is a way to avoid the dynamic initialization
> or defer it
> >> until runtime (i.e., initialize the handler lazily)
> >
> > We need initialize the handler before first operator
> new() call (or
> > from first oprator new() call), but I have not see the possible way
> > for this.
>
> I wonder if defining DllMain() and setting the handler there,
> for DLLs only, would deal with the initialization dependency
> issue, albeit at the cost of a (small) runtime hit.
Setting handler from DllMain() is the same as the solution, provided
in my patch,
because of global objects are constructed from DllMain() (exactly
function name
is DllMainCRTStartup()). The #pragma init_seg(dll) only tells, that
objects in
current .cpp file will be constructed before objects from modules with
#pragma init_seg(user), and ordinary global objects (but after the
objects
from modules with #pragma init_seg(compiler)). The MSVC initializes CRT
global
objects using #pragma init_seg(compiler).
Farid.
Re: [PATCH] STDCXX-77
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Tuesday, August 28, 2007 7:11 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] STDCXX-77
>>
>> I have one concern with the introduction of dynamic
>> initialization and the pragma into the library. First, our
>> (undocumented) design goal is to avoid requiring dynamic
>> initialization in the library.
>> I.e., there should be no code in the library that runs at startup.
>> The rationale for it is efficiency and avoiding user code
>> issues due to initialization dependencies. Since other
>> libraries may use the same pragma, they will be subject to
>> initialization dependencies that we try to avoid.
>>
>> Unless there is a way to avoid the dynamic initialization or
>> defer it until runtime (i.e., initialize the handler lazily)
>
> We need initialize the handler before first operator new() call
> (or from first oprator new() call), but I have not see the possible way
> for this.
I wonder if defining DllMain() and setting the handler there,
for DLLs only, would deal with the initialization dependency
issue, albeit at the cost of a (small) runtime hit.
But given what we said about it being fixed in MSVC 8 I don't
think even this is worth the trouble. Not to mention that the
solution wouldn't work for archive libraries.
Martin
RE: [PATCH] STDCXX-77
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Tuesday, August 28, 2007 7:11 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] STDCXX-77
>
> I have one concern with the introduction of dynamic
> initialization and the pragma into the library. First, our
> (undocumented) design goal is to avoid requiring dynamic
> initialization in the library.
> I.e., there should be no code in the library that runs at startup.
> The rationale for it is efficiency and avoiding user code
> issues due to initialization dependencies. Since other
> libraries may use the same pragma, they will be subject to
> initialization dependencies that we try to avoid.
>
> Unless there is a way to avoid the dynamic initialization or
> defer it until runtime (i.e., initialize the handler lazily)
We need initialize the handler before first operator new() call
(or from first oprator new() call), but I have not see the possible way
for this.
> I would just as soon add the patch to the Jira issue and
> close it as Won't Fix.
Farid.
Re: [PATCH] STDCXX-77
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
> Attached is a patch to make operator new on MSVC conforming to the C++
> Standard.
I have one concern with the introduction of dynamic initialization
and the pragma into the library. First, our (undocumented) design
goal is to avoid requiring dynamic initialization in the library.
I.e., there should be no code in the library that runs at startup.
The rationale for it is efficiency and avoiding user code issues
due to initialization dependencies. Since other libraries may use
the same pragma, they will be subject to initialization dependencies
that we try to avoid.
Unless there is a way to avoid the dynamic initialization or defer
it until runtime (i.e., initialize the handler lazily) I would just
as soon add the patch to the Jira issue and close it as Won't Fix.
Martin
> ChangeLog:
> * _config-msvcrt.h: #undefine _RWSTD_NO_NEW_THROWS and
> _RWSTD_NO_NEW_OFLOW_SAFE macros if they're #defined.
> * memory.cpp (__rw_new_handler_imp): Throw std::bad_alloc() if no user
> handler installed.
> (set_new_handler): Don't invoke _set_new_handler().
> * new_supp.cpp: New file with helper object to make operator new
> conforming to the C++ Standard
>
> Farid.
>
>
> ------------------------------------------------------------------------
>
> Index: include/rw/_config-msvcrt.h
> ===================================================================
> --- include/rw/_config-msvcrt.h (revision 570339)
> +++ include/rw/_config-msvcrt.h (working copy)
> @@ -148,6 +148,14 @@
> # define _RWSTD_NO_DEPRECATED_C_HEADERS
> #endif // _RWSTD_NO_DEPRECATED_C_HEADERS
>
> +#ifdef _RWSTD_NO_NEW_THROWS
> +# undef _RWSTD_NO_NEW_THROWS
> +#endif // _RWSTD_NO_NEW_THROWS
> +
> +#ifdef _RWSTD_NO_NEW_OFLOW_SAFE
> +# undef _RWSTD_NO_NEW_OFLOW_SAFE
> +#endif // _RWSTD_NO_NEW_OFLOW_SAFE
> +
> // operator new and delete is not reliably replaceable across
> // shared library boundaries, which includes the shared library
> // version of the language support library
> Index: src/memory.cpp
> ===================================================================
> --- src/memory.cpp (revision 570339)
> +++ src/memory.cpp (working copy)
> @@ -178,20 +178,22 @@
>
> #ifdef _MSC_VER
>
> -typedef int (*__rw_new_handler_t)(_RWSTD_SIZE_T);
> -
> -_RWSTD_DLLIMPORT __rw_new_handler_t _set_new_handler (__rw_new_handler_t);
> -
> _RWSTD_NAMESPACE (__rw) {
>
> static _STD::new_handler __rw_new_handler /* = 0 */;
>
> -static int __rw_new_handler_imp (_RWSTD_SIZE_T)
> +int __rw_new_handler_imp (_RWSTD_SIZE_T)
> {
> - _RWSTD_ASSERT (0 != __rw_new_handler);
> + if (!__rw_new_handler)
> +#if _MSC_VER <= 1310
> + _RW::__rw_throw (_RWSTD_ERROR_FIRST + 3 /* == bad_alloc */);
> +#else
> + return 0; // operator new will throw std::bad_alloc()
> +#endif
>
> __rw_new_handler ();
>
> + // repeat memory allocation
> return 1;
> }
>
> @@ -214,8 +216,6 @@
>
> _RW::__rw_new_handler = handler;
>
> - _set_new_handler (_RW::__rw_new_handler_imp);
> -
> return save;
> }
>
> Index: src/new_supp.cpp
> ===================================================================
> --- src/new_supp.cpp (revision 0)
> +++ src/new_supp.cpp (revision 0)
> @@ -0,0 +1,58 @@
> + /***************************************************************************
> + *
> + * new_supp.cpp - helper object to make operator new conforming
> + * to the C++ Standard
> + *
> + * $Id$
> + *
> + ***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + **************************************************************************/
> +
> +#define _RWSTD_LIB_SRC
> +
> +#ifdef _MSC_VER
> +
> +#include <rw/_defs.h>
> +
> +
> +typedef int (*__rw_new_handler_t)(_RWSTD_SIZE_T);
> +
> +_RWSTD_DLLIMPORT __rw_new_handler_t _set_new_handler (__rw_new_handler_t);
> +
> +_RWSTD_NAMESPACE (__rw) {
> +
> +int __rw_new_handler_imp (_RWSTD_SIZE_T);
> +
> +} // namespace __rw
> +
> +
> +#pragma init_seg (lib)
> +
> +struct __rw_new_handler_init_t
> +{
> + __rw_new_handler_init_t () {
> + _set_new_handler (_RW::__rw_new_handler_imp);
> + }
> +};
> +
> +static __rw_new_handler_init_t __rw_new_handler_init;
> +
> +
> +#endif // _MSC_VER
>
> Property changes on: src\new_supp.cpp
> ___________________________________________________________________
> Name: svn:keywords
> + Id
> Name: svn:eol-style
> + native
>