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?
>There cases where the penalty for this check coul
Hello!
> I was wondering, if:
>
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_CORE2 | m_GENERIC),
>
> is correct. Should it be:
>
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_GENERIC),
>
> ?
inc/dec has the same performance as add/sub on Core 2 Duo. But
inc/de
* Karl Chen:
> "4 * n", unchecked, is vulnerable to integer overflow. On IA-32,
> "new int[0x4001]" becomes equivalent to "new int[1]". I've
> verified this on gcc-2.95 through 4.1. For larger objects the
> effects are exaggerated; smaller counts are needed to overflow.
This PR19351, by th
Florian Weimer wrote:
This PR19351, by the way.
The most widespread interpretation of the standard is that conforming
implementations aren't allowed to raise an exception in this case:
the arithmetic is defined to occur in terms of an unsigned type.
Well for sure the standard does not allow y
2007/4/7, Ross Ridge <[EMAIL PROTECTED]>:
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 c
J.C. Pizarro wrote:
A solution is using the -shared option to generate ".so" library.
That does not solve things in environments like embedded
environments where there are no shared libraries.
Another future solution is pack the big ".so" library with UPX
(Ultimate Packer for eXecutables) or
2007/4/7, Robert Dewar <[EMAIL PROTECTED]>:
> A solution is using the -shared option to generate ".so" library.
That does not solve things in environments like embedded
environments where there are no shared libraries.
Use -Os and "strip --strip-all". And remove code if you don't like it.
>
2007/4/7, Robert Dewar <[EMAIL PROTECTED]>:
> > A solution is using the -shared option to generate ".so" library.
>
> That does not solve things in environments like embedded
> environments where there are no shared libraries.
Use -Os and "strip --strip-all". And remove code if you don't like it.
[EMAIL PROTECTED] (Ross Ridge) writes:
| 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?
On Sat, Apr 07, 2007 at 11:29:46AM +0200, Uros Bizjak wrote:
> Hello!
>
> >> I was wondering, if:
> >>
> >> /* X86_TUNE_USE_INCDEC */
> >> ~(m_PENT4 | m_NOCONA | m_CORE2 | m_GENERIC),
> >>
> >> is correct. Should it be:
> >>
> >> /* X86_TUNE_USE_INCDEC */
> >> ~(m_PENT4 | m_NOCONA | m_
Hi there,
I'm actively working on a patch for enhancement request PR14331, which is
still currently in 'NEW' state. Would some kindly admin like to assign it to
me?
cheers,
DaveK
--
Can't think of a witty .sigline today
On Saturday 07 April 2007 15:28, Dave Korn wrote:
> Hi there,
>
> I'm actively working on a patch for enhancement request PR14331, which is
> still currently in 'NEW' state. Would some kindly admin like to assign it
> to me?
Didn't you get bugzilla super-powers with your write after approva
On 07 April 2007 15:37, Paul Brook wrote:
> On Saturday 07 April 2007 15:28, Dave Korn wrote:
>> Hi there,
>>
>> I'm actively working on a patch for enhancement request PR14331, which is
>> still currently in 'NEW' state. Would some kindly admin like to assign it
>> to me?
>
> Didn't you
On 4/7/07, Dave Korn <[EMAIL PROTECTED]> wrote:
No, looks like an oversight; there are no permission bits listed on my user
prefs. I logged out and logged back in to get a fresh cookie, still no
difference.
Including your @gcc.gnu.org account?
-- Pinski
On 07 April 2007 16:01, Andrew Pinski wrote:
> On 4/7/07, Dave Korn <[EMAIL PROTECTED]> wrote:
>> No, looks like an oversight; there are no permission bits listed on my
>> user prefs. I logged out and logged back in to get a fresh cookie, still
>> no difference.
>
> Including your @gcc.gnu.org
On 06/04/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Fri, Apr 06, 2007 at 11:38:50AM +0100, Rob Quill wrote:
> So the general concensus is that's it's not worth doing?
> Hypothetically, if I did it and it didn't make much difference, would
> it be worth submitting a patch? Or should I just give up
On Sat, Apr 07, 2007 at 12:15:10PM +0200, Florian Weimer wrote:
> * Karl Chen:
>
> > "4 * n", unchecked, is vulnerable to integer overflow. On IA-32,
> > "new int[0x4001]" becomes equivalent to "new int[1]". I've
> > verified this on gcc-2.95 through 4.1. For larger objects the
> > effects
Rob Quill wrote:
OK, that sounds good to me. As you say, there is no way to know until
it is actually implemented how muh affect it will have. However, I
won't be able to start on it until summer as I have to worry about
sitting my finals, so I'll let you know when I get started.
I would say t
Gerald,
I do not have easy access to the HTML repository anymore.
Martin Michlmayr asked me to add to the 4.2 changes list the inclusion
of the new compile time option -fargument-noalias-anything.
I constructed the following out of the invoke.texi document, to be
included in gcc-4.2/changes.
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).
Ross Ridge writes:
>What do you do if the user has defined his own operator new that does
>something else?
Gabriel Dos Reis writes:
>Mor
[EMAIL PROTECTED] (Ross Ridge) writes:
| 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).
|
| Ross Ridge writes:
| >What do you do if the user has defined his own operator new that
[EMAIL PROTECTED] (Ross Ridge) writes:
> Well, for example, like all other things that a new_handler can do,
> like throwing an exception derived from bad_alloc or calling exit().
> In addition, any number of side effects are possible, like printing
> error messages or setting flags.
Gabriel Dos R
Gabriel Dos Reis writes:
> >I believe you're confused about the semantics.
> >The issue here is that the *size of object* requested can be
> >represented. That is independent of whether the machine has enough
> >memory or not. So, new_handler is a red herring
On Sat, Apr 07, 2007 at 06:05:35P
On Sat, Apr 07, 2007 at 04:01:57PM -0500, Gabriel Dos Reis wrote:
> [EMAIL PROTECTED] (Ross Ridge) writes:
>
> | 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).
> |
> | Ross Ri
On Sat, Apr 07, 2007 at 07:41:59AM -0400, Robert Dewar wrote:
> J.C. Pizarro wrote:
>
> >A solution is using the -shared option to generate ".so" library.
>
> That does not solve things in environments like embedded
> environments where there are no shared libraries.
> >
> >Another future solutio
Joe Buck <[EMAIL PROTECTED]> writes:
| This is why I suggested that, should we implement a better check,
| there should be an option to turn it off, so programmers who cannot
| afford an extra byte are taken care of.
I agree.
-- Gaby
[EMAIL PROTECTED] (Ross Ridge) writes:
[...]
| Gabriel Dos Reis writes:
| >I believe you're confused about the semantics.
| >The issue here is that the *size of object* requested can be
| >represented. That is independent of whether the machine has enough
| >memory or not. So, new_handler is
Joe Buck writes:
>Consider an implementation that, when given
>
>Foo* array_of_foo = new Foo[n_elements];
>
>passes __compute_size(elements, sizeof Foo) instead of n_elements*sizeof Foo
>to operator new, where __compute_size is
>
>inline size_t __compute_size(size_t num, size_t size) {
>
28 matches
Mail list logo
