This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Integer overflow in operator new
- From: "J.C. Pizarro" <jcpiza at gmail dot com>
- To: "Ross Ridge" <rridge at csclub dot uwaterloo dot ca>, Buck <Joe dot Buck at synopsys dot com>, "Gabriel Dos Reis" <gdr at cs dot tamu dot edu>, "David Daney" <ddaney at avtrex dot com>, "Andrew Pinski" <pinskia at gmail dot com>, "Karl Chen" <quarl at cs dot berkeley dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 7 Apr 2007 13:37:40 +0200
- Subject: Re: Integer overflow in operator new
- References: <20070407070455.57937740E3@caffeine.csclub.uwaterloo.ca>
2007/4/7, Ross Ridge <rridge@csclub.uwaterloo.ca>:
Joe Buck writes:
>If a check were to be implemented, the right thing to do would be to throw
>bad_alloc (for the default new) or return 0 (for the nothrow new).
What do you do if the user has defined his own operator new that does
something else?
The callees checkers should to be with optional stubs, by example, the user
wants to catch the error, log and send an e-mail to him and to data center.
>There cases where the penalty for this check could have
>an impact, like for pool allocators that are otherwise very cheap.
>If so, there could be a flag to suppress the check.
Excessive code size growth could also be problem for some programs.
A solution is using the -shared option to generate ".so" library.
Another future solution is pack the big ".so" library with UPX
(Ultimate Packer for eXecutables) or extend the ELF format to
permit pack the sections with GZ, BZ2 or LZMA.
Ross Ridge
J.C. Pizarro.