new and malloc

[SpS]

as new throws exception bad_alloc...does malloc also throws exception of some kind???

[Narue]

No, malloc returns a null pointer if it fails, just like in C. So you should always test for success like this:

p = malloc ( n * sizeof *p );
if ( p == NULL ) {
  // Handle malloc failure
}

Of course, in C++ there's little need to use malloc instead of new, so the point is really moot unless you're writing cross language libraries.

[SpS]

#include<iostream.h>
#include<malloc.h>
  int main()
  {
         int *n;
		 n= (int*)malloc(-1);
		if(n==NULL)
			cout<<"Gotcha";
		else
			cout<<"OOPS";

          return 0;
  }

Why does this code not prints Gotcha if malloc returns NULL(On failure)

[SpS]

And 1 more thing....i've checked in online MSDN library...they say new operator returns null or an exception

Is throwing exception not a standard??

[Stoned_coder]

yes it is standard, but it took a while for some compilers to catch up, most notably msvc6. There is also a nothrow version of new specified by the standard.

[Narue]

>#include<malloc.h>
Get with the times, malloc is declared in cstdlib (or stdlib.h for people who insist on using ancient compilers) and has been for a long time.

>n= (int*)malloc(-1);
It's surprising that this actually works, but it's possible (thought not incredibly bright) to allocate that much memory. Remember that malloc takes an unsigned type as the argument, so your -1 is being converted to a very large number

>Why does this code not prints Gotcha if malloc returns NULL(On failure)
What makes you think it failed if it didn't return NULL?

[SpS]

>#include<malloc.h>

What makes you think it failed if it didn't return NULL?

Actually i tried this with new operator like new int[-1]..it failed and throwed exception.
Then i tried with malloc(-1)...it again failed but never reached at
if (n==NULL) condition and didn't threw any exception

[Narue]

>it again failed but never reached at if (n==NULL) condition and didn't threw any exception
Oh, I see. You crashed your program by causing the memory manager to panic and you're wondering why your code didn't magically stop it. I can understand your confusion.

[SpS]

>it again failed but never reached at if (n==NULL) condition and didn't threw any exception
Oh, I see. You crashed your program by causing the memory manager to panic and you're wondering why your code didn't magically stop it. I can understand your confusion.

Initially i thought that malloc is also throwing exception like new...so i was trying to catch it the way i was catchin new operator's exception....but since u told me that malloc throws null on failure...so i tried to check for null condition and it didn't even reached there..this is what i wanted to say/ask...

[Narue]

>but since u told me that malloc throws null on failure
malloc doesn't throw null, it returns NULL. There's sufficient difference that you should avoid mixing the two.

>this is what i wanted to say/ask...
Well, you didn't specify how it didn't work, but on one of my compilers, there's a run-time assertion if the allocation size exceeds a certain limit, and 4294967295 is beyond that limit. Such an assertion throws up a dialog box and aborts the program, which could look like an uncaught exception. You're probably seeing something like that, and because the assertion stops the program before malloc returns, no about of testing the return value will save you.

[Ancient Dragon]

> there's a run-time assertion if the allocation size exceeds a certain limit, and 4294967295 is beyond that limit.

The parameter to malloc is a size_t (on my compiler it is defined as unsigned long). So how in the world can you ever pass that function a value greater than what can be stored in size_t (that is, the function will never receive a value greater than that).

If it can't, then how will your compiler ever be able to generate a run-time assertion? Or do you really mean the compiler generates a compile-time warning or error? :?:

[Narue]

>So how in the world can you ever pass that function a value greater than what can be stored in size_t
You can't, but that's not the point.

>If it can't, then how will your compiler ever be able to generate a run-time assertion?
Just because malloc accepts a size_t value doesn't mean the memory manager can handle a request for the full extent of size_t's range at any given time, or even at all.

>Or do you really mean the compiler generates a compile-time warning or error?
I think I know the difference between a run-time assertion and a compile-time warning or error. :rolleyes:

[Ancient Dragon]

>>If it can't, then how will your compiler ever be able to generate a run-time assertion?
Just because malloc accepts a size_t value doesn't mean the memory manager can handle a request for the full extent of size_t's range at any given time, or even at all.:

but that's not the same thing as your previous statement. Previously you stated an assertion was raised if a value greater than size_t was passed. I said that's impossible. Nobody mentioned passing values less than size_t.

[Narue]

>Previously you stated an assertion was raised if a value greater than size_t was passed.
Bzzt! Sorry, but please read what I actually said instead of your own butchered interpretation of what I said. I'll quote it for your convenience:

there's a run-time assertion if the allocation size exceeds a certain limit, and 4294967295 is beyond that limit

Notice that I said nothing about size_t, only an unspecified internal limit and that -1 wrapped around to an unsigned type is beyond that limit for the compiler in question.

[Ancient Dragon]

I used size_t because that's how malloc() is prototyped. http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html

[Narue]

>I used size_t because that's how malloc() is prototyped.
Are you intentionally being dense? Because this is beginning to feel like a troll. Anyway, all points have been made, so I'm closing this thread. If the OP has further questions, he can start a new thread.