This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: C++ std headers and malloc, realloc poisoning

From: Jason Merrill <jason at redhat dot com>
To: Jakub Jelinek <jakub at redhat dot com>
Cc: Oleg Endo <oleg dot endo at t-online dot de>, gcc <gcc at gcc dot gnu dot org>
Date: Thu, 05 Dec 2013 10:45:59 -0500
Subject: Re: C++ std headers and malloc, realloc poisoning
Authentication-results: sourceware.org; auth=none
References: <1386188468 dot 2269 dot 52 dot camel at yam-132-YW-E178-FTW> <529F9747 dot 5070807 at redhat dot com> <20131204210353 dot GA892 at tucnak dot redhat dot com>

On 12/04/2013 04:03 PM, Jakub Jelinek wrote:

I think the most important reason is that we want to handle out of mem
cases consistently, so instead of malloc etc. we want users to use xmalloc
etc. that guarantee non-NULL returned value, or fatal error and never
returning.  For operator new that is solvable through std::set_new_handler
I guess, but for malloc we really don't want people to deal with checking
NULL return values from those everywhere.

A simple workaround would be to disable poisoning of malloc/realloc onOS X (or when the build machine uses libc++, if that's easy to detect).


Jason

Follow-Ups:
- Re: C++ std headers and malloc, realloc poisoning
  - From: Oleg Endo

References:
- C++ std headers and malloc, realloc poisoning
  - From: Oleg Endo
- Re: C++ std headers and malloc, realloc poisoning
  - From: Jason Merrill
- Re: C++ std headers and malloc, realloc poisoning
  - From: Jakub Jelinek

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]