new returning 0

[Noah Roberts]

It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

 

[Victor Bazarov]

It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using
new returning 0 instead of throwing an exception. I'm not the one
dealing with the code but I told that person he might expect an
exception and thus sent him on a wild goose chase. Where did I go
wrong?

Some old compilers didn't have the proper implementation of 'new'...

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

Huh? I think it's answered in the FAQ 5.8...

V

 

[Fei Liu]

It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

1. you can override 'operator new'
2. there is std::nothrow

Returning 0 from new is a convenience feature imo. For the past 10
years, people have been writing code like
if( !(x = new classA) ){ handle_new_error(); }

 

[red floyd]

It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

std::nothrow is defined in <new>

#include <new>
#include <stdexcept>
#include <iostream>
#include <ostream>

int main()
{
int *pint = 0;
try
{
pint = new int[10];
}
catch (std::bad_alloc& e)
{
std::cout << "new failed: "
<< e.what()
<< std::endl;
}

delete[] pint;

pint = new(std::nothrow) int[10];
if (!pint)
{
std::cout << "new(std::nothrow) failed" << std::endl;
}
delete[] pint;

return 0;
}

 

[Noah Roberts]

It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

What I mean is that the code is not using std::nothrow nor is it
overriding operator new, so these are not the reasons why new is
returning 0.

 

[Noah Roberts]

Some old compilers didn't have the proper implementation of 'new'...

Yeah, msvc++ 8 isn't exactly old.

Huh? I think it's answered in the FAQ 5.8...

I don't see it. I think you're mistaken.

 

[Zeppe]

Yeah, msvc++ 8 isn't exactly old.

I don't see it. I think you're mistaken.

Victor meant that if your code doesn't work as you expect (and it
obviously doesn't) and you ask a question about that, you have to follow
the guideline of the FAQ 5.8. Of course, in this case this translates
to: "post the code that does not work".

Regards,

Zeppe

 

[Noah Roberts]

Victor meant that if your code doesn't work as you expect (and it
obviously doesn't) and you ask a question about that, you have to follow
the guideline of the FAQ 5.8. Of course, in this case this translates
to: "post the code that does not work".

Yeah, not exactly applicable in cases like this and I'm not finding
pedantic nonsense very helpful, sorry.

If you can't answer the question, don't answer the question.

 

[Victor Bazarov]

[..]

If you can't answer the question, don't answer the question.

You've earned a position in my killfile for the second time!
Welcome back, Noah!

 

[Lionel B]

What I mean is that the code is not using std::nothrow nor is it
overriding operator new, so these are not the reasons why new is
returning 0.

Right. Your original post was unclear. Just to get it straight, you are
saying that in some instances new (array version, not using std::nothrow,
not overridden) is not throwing an exception, but rather returning 0.

The only thing I can think of is that perhaps the compiler is being
invoked with some strange switch leading to non-standard behaviour.

A minimal example demonstrating the problem might be useful - perhaps
someone with the same compiler might be able to cast some light (and of
course creating minimal examples frequently throws up the answer).

 

[Zeppe]

Yeah, not exactly applicable in cases like this and I'm not finding
pedantic nonsense very helpful, sorry.

If you can't answer the question, don't answer the question.

Ok, a less pedantic nonsense, then: given that my vc8 throws bad_alloc,
or your vc8 is different from mine, or you are talkin bullshit. I dunno
why, but i guess the latter.

bye

Zeppe

 

[Noah Roberts]

[..]

If you can't answer the question, don't answer the question.

You've earned a position in my killfile for the second time!
Welcome back, Noah!

yay!!! Does this mean I don't have to put up with your inane replies
anymore??

 

[Noah Roberts]

Right. Your original post was unclear. Just to get it straight, you are
saying that in some instances new (array version, not using std::nothrow,
not overridden) is not throwing an exception, but rather returning 0.

The only thing I can think of is that perhaps the compiler is being
invoked with some strange switch leading to non-standard behaviour.

That's my thought too but I can't find it.

A minimal example demonstrating the problem might be useful - perhaps
someone with the same compiler might be able to cast some light (and of
course creating minimal examples frequently throws up the answer).

Such a sample cannot be created. Not without knowing how to do so; of
course, I've only spent 4 hours trying. All versions, even those with
exceptions turned off, throw a bad_alloc.

Once I know how to create the problem I can solve it by reversing that
creation in the problem program.

 

[Noah Roberts]

Lionel B wrote:

Such a sample cannot be created. Not without knowing how to do so; of
course, I've only spent 4 hours trying. All versions, even those with
exceptions turned off, throw a bad_alloc.

Once I know how to create the problem I can solve it by reversing that
creation in the problem program.

More on my attempt to solve the problem or even recreate it:

The program that is doing this uses a DLL that is allocating the memory.
I don't know if being a DLL has anything to do with it or not because
I've tried going down that road as well. One thing for certain, the
problem program is calling a non-standard operator new (size_t, int,
char const*, int) inside of dbgnew.cpp. I can't get my small version to
call this function.

I think I'm treading too far into implementation specific behavior to
get much help here (especially with the police population) but maybe
someone has seen this, maybe not.

 

[Noah Roberts]

More on my attempt to solve the problem or even recreate it:

The program that is doing this uses a DLL that is allocating the memory.
I don't know if being a DLL has anything to do with it or not because
I've tried going down that road as well. One thing for certain, the
problem program is calling a non-standard operator new (size_t, int,
char const*, int) inside of dbgnew.cpp. I can't get my small version to
call this function.

I think I'm treading too far into implementation specific behavior to
get much help here (especially with the police population) but maybe
someone has seen this, maybe not.

I got a repro on the problem. I now know the cause and can do something
about it. Someone was being clever.

 

[Jacek Dziedzic]

I got a repro on the problem. I now know the cause and can do something
about it. Someone was being clever.

And? I am curious to what actually happened.

- J.

 

[Noah Roberts]

And? I am curious to what actually happened.

The MSVC++ library has this funky "debug" new that has the previously
described signature. It is called something like so:

new(_NEWBLOCK, size, __FILE__, __LINE__) object;

I don't know if that's the real thing but it's the general idea.

Someone was being clever, had defined a macro for that and then done this:

#define new DEBUG_NEW

So all the calls to new in the source where doing some stupid
non-standard, compiler specific, allocation call that acts like
pre-exception new and returns 0. It dawned on me what was going on
right after I posted the entry just before saying I figured it out and
it only took a bit to verify.

I was hoping that figuring this out might solve the underlying
allocation problem but no such luck. We just know why it wasn't
behaving as the standard describes.

 

[Gianni Mariani]

Noah Roberts wrote:
....

I was hoping that figuring this out might solve the underlying
allocation problem but no such luck. We just know why it wasn't
behaving as the standard describes.

I assume now you see bad_alloc exceptions and you don't know why ?
Maybe a corrupted heap ?

 

[Noah Roberts]

Noah Roberts wrote:
...

I assume now you see bad_alloc exceptions and you don't know why ? Maybe
a corrupted heap ?

Could be. The developer that made that code was the same one that
insisted on using char* instead of strings and vectors. The same one
that dictated to the whole team that we where not to use exceptions.
The same one that didn't like templates and the STL because they're,
"slow and bloated." The same one that adhered strictly to the NIH paradigm.

We were all quite upset to see him go.

I think they're giving up on it; my involvement kind of ended when I
discovered why it wasn't doing what I said it should be doing. It only
happens in some obscure condition under this weird test when running on
windows 2000 in a VM. We don't expect that to come up a whole lot with
our customer use patterns. Something to fix later when we're screwing
with that program again...something that might get fixed just by slowly
changing code to use more reasonable coding standards.

 

[Gianni Mariani]

Gianni Mariani wrote: ....
....

I think they're giving up on it; my involvement kind of ended when I
discovered why it wasn't doing what I said it should be doing. It only
happens in some obscure condition under this weird test when running on
windows 2000 in a VM.

That's probably still a bug in the application code that will bite you
on your first deployment to a paying customer.

... We don't expect that to come up a whole lot with
our customer use patterns. Something to fix later when we're screwing
with that program again...something that might get fixed just by slowly
changing code to use more reasonable coding standards.

Exceptions are kind of special in that I don't often see them used
correctly. Often programmers use it as a return value passing mechanism
rather than "fixing" the interfaces.

Exceptions in C++ could be much better - the nothrow semantics for
example could be compile-time enforced. Debugging with exceptions can
be non-trivial because you loose the context of the exception - this
needs the programmer to log much more information in the case of an
exception.

Exceptions are also used often where and abort should be. A coding
error should be terminal - i.e. stop the process and dump a core file
yet many developers throw an exception hoping to recover only further
exacerbating the problems. Classic case - I use a CAD program, when it
dies, it tries to save the work in progress only to often end up
corrupting the previously saved version.

While template phobia and not using constructors correctly are valid
criticisms, a healthy dose of reality check of use of exceptions is
something that needs to be evaluated more closely.