Using malloc in C++?

[Owen Jacobson]

Yes. The inference being my code will now magically work ?

How does this not break code that assumes a non-failure case returns
non-null ?

If that code is correctly written then it will simply see malloc as
consistently failing iff it returns NULL on malloc(0). Returning NULL
from malloc(0) is not magically a success case for that one input
value and a failure case for every other value.

Any code that assumes malloc won't return NULL and isn't prepared to
handle it is already broken, regardless of the parameter to malloc.

 

[Gianni Mariani]

Gianni Mariani wrote: ....

I don't understand the question. What results would you expect from
malloc(0)?

I think that was already covered.

... Why would the implementation-defined nature make a
difference?

You can't figure that out ?

... Even when malloc(0) "succeeds", that is returns a non-null
pointer, you can't access the allocated memory.

Why do you need to access the memory - you have a pointer.

... All you can do is
compare the pointer for equality or pass it to free().

Exactly.

So what don't you get ?

 

[Gianni Mariani]

Owen Jacobson wrote:
....

Any code that assumes malloc won't return NULL and isn't prepared to
handle it is already broken, regardless of the parameter to malloc.

Why is it broken ? It might be perfectly valid. I can think of at
least 2 examples of valid code that will work for one implementation of
malloc and not the other.

 

[Ian Collins]

Owen Jacobson wrote:
....

Why is it broken ? It might be perfectly valid. I can think of at
least 2 examples of valid code that will work for one implementation of
malloc and not the other.

Care to enlighten us?

 

[Ian Collins]

Different behaviour on different systems. If I write code that assumes
malloc(0) returns unique values and it returns 0 on some, it will break.

Why would you want to do that?

 

[Gianni Mariani]

Care to enlighten us?

struct mystring
{

mystring( int len )
: len( len ),
ptr( malloc( len )
{
if ( ! ptr )
{
throw bad_alloc;
}
}
......

};

 

[Gianni Mariani]

Ian Collins wrote:
....

Why would you want to do that?

I would not.

Have you forgotten the topic of this thread ? Why are you asking that
question ?

 

[Owen Jacobson]

struct mystring
{

mystring( int len )
: len( len ),
ptr( malloc( len )
{
if ( ! ptr )
{
throw bad_alloc;
}
}
......

};

Allowing for typos (you're missing the closing ) on the initialisation
of ptr), I don't see anything about that code that's broken by
malloc(0) returning NULL. The constructor as written validates the
assumption that a block of memory representing the string is available
and fails construction if not. That's a perfectly reasonable
assumption for the ensuing, elided code to make.

Keep in mind that, as written, malloc(23) is allowed to always return
NULL too -- it's a quality of implementation issue that it doesn't,
not a conformance issue. On such a system, mystring(23) would always
fail because the assumption it validates is not satisfied by that
system.

 

[Ian Collins]

Ian Collins wrote:
....

I would not.

Have you forgotten the topic of this thread ? Why are you asking that
question ?

This branch has drifted away form the original question and descended
into a pointless argument about the portability of malloc(0), which you
have just conceded you wouldn't do.

 

[Default User]

I think that was already covered.


You can't figure that out ?

No, I can't.

Why do you need to access the memory - you have a pointer.

For what purpose?

Exactly.

Exactly what?

So what don't you get ?

What you would expect the code do? What differential behavior would be
important to program flow?




Brian

 

[Old Wolf]

Different behaviour on different systems. If I write code that
assumes malloc(0) returns unique values and it returns 0 on some,
it will break.

It's your error for making assumptions not guaranteed
by the standard. If I write code that assumes 'new'
never throws, should I blame the language when it
does throw?

I'm not sure if that's the only one but it is a source of
inconsistency between platforms.

If you want a language without implementation-defined
behaviour, then C++ is not for you.

 

[Gianni Mariani]

Default User wrote:
....

What you would expect the code do? What differential behavior would be
important to program flow?

Because of different behaviour on different platforms, code may work on
one platform and not another. In the context of the OP, this suggests
to use new over malloc since the standard behaviour for new is
consistent across all platforms (modulo bugs).

 

[Gianni Mariani]

Allowing for typos (you're missing the closing ) on the initialisation
of ptr), I don't see anything about that code that's broken by
malloc(0) returning NULL.

What about that exception on one platform and not another for mystring(0) ?

It's a really simple concept here, why don't you get it ? Different
"standard" behaviour on different platforms leads to less portable code
which is the statement Torsten made which is now obvious.

Sure *I* can write code that works correctly on all platforms, so what ?
The read question is, can there exist conforming code that works on
one platform and not another. That is obviously true (by existence).

... The constructor as written validates the
assumption that a block of memory representing the string is available
and fails construction if not. That's a perfectly reasonable
assumption for the ensuing, elided code to make.

Keep in mind that, as written, malloc(23) is allowed to always return
NULL too -- it's a quality of implementation issue that it doesn't,
not a conformance issue. On such a system, mystring(23) would always
fail because the assumption it validates is not satisfied by that
system.

What ? malloc(23) should only return null in the case of a bug (non
conformance) or inability to allocate memory (bad_alloc). Are you
advocating otherwise ?

 

[Gianni Mariani]

It's your error for making assumptions not guaranteed
by the standard. If I write code that assumes 'new'
never throws, should I blame the language when it
does throw?

Dear Old. It's not the point. The point is portability.

 

[Gianni Mariani]

This branch has drifted away form the original question and descended
into a pointless argument about the portability of malloc(0), which you
have just conceded you wouldn't do.

I never said I would do. I've seen code that does.

You may have thought that the thread topic drifted, I didn't which may
seem to explain why it went this way.

 

[Owen Jacobson]

What about that exception on one platform and not another for mystring(0) ?

Or, for that matter, the exception that that code throws sometimes but
not other times on a single platform, within the same execution? Or
that that code always throws on a given platform, when run under high
load, but never throws on the same platform under low load? Or any of
a number of other circumstances?

What ? malloc(23) should only return null in the case of a bug (non
conformance) or inability to allocate memory (bad_alloc). Are you
advocating otherwise ?

The C standard, from whence malloc comes, is extremely conservative
when it comes to defining what standard library functions that have
side effects are required to do. The verbiage in C99 is as follows:

If the space cannot be allocated, a null pointer is
returned.

It does not say "If the space is unavailable", or "If memory is full",
or anything else, merely "if the space cannot be allocated." As I
said: it's a quality of implementation issue; a sufficiently poor
implementation may never be able to allocate exactly 23 bytes and
unwilling to allocate more than requested. Such an implementation
would be conformant, even though it would likely have no users.

The standard does continue on to describe what appears to be a special
case for malloc(0):

If the size of the space requested is zero, the behavior is
implementation-
defined: either a null pointer is returned, or the behavior is as if
the size
were some nonzero value, except that the returned pointer shall not
be used
to access an object.

However, on closer analysis both of these cases can be derived from
the general behaviour of malloc described elsewhere: 1. that
arithmetic on the returned pointer be limited to the half-open
interval [x, x+size), which is an empty interval when size is 0, and
2. that malloc may return NULL. Therefore this is not a special case,
and implementations that return NULL on malloc(0) even when memory is
available are merely poor implementations.

Isn't it time to get these implementations fixed, Gianni?

 

[Owen Jacobson]

Oh, dammit. I haven't been quite precise enough.

1. that arithmetic on the returned pointer be limited to the half-open
interval [x, x+size), which is an empty interval when size is 0

1. That only pointers that fall in that half-open interval may be
*dereferenced* -- valid pointer values are actually those in the
closed interval [x, x+size], which has exactly one element (x) for
size = 0.

 

[srimks11]

I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one
should instead use new and delete.

But why is that a problem? I cannot see why using malloc instead of new
does not give the same result.

Please refer below, I had modified recently -
http://wiki.answers.com/Q/What_is_the_difference_between_malloc_and_new_other_than_syntax

BR
Mukesh

 

[Jack Klein]

struct mystring
{

mystring( int len )
: len( len ),
ptr( malloc( len )
{
if ( ! ptr )

Replace the line above with:

if (len && !ptr)

{
throw bad_alloc;
}
}
......

};

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Gianni Mariani]

... Or any of
a number of other circumstances?

Chinese fish prices not withstanding ?

I don't see the relevance of this to this thread. We're talking about
portability issues of malloc over new. Someone assered that malloc
behaves differently on different platforms. My recollection was that
free(0) and malloc(0) used to be poorly specified. Someone said that
malloc(0) has two standard behaviours and I said QED. How this relates
to code throwing exceptions is about as relevant as PRC fish prices.

....

The C standard, from whence malloc comes, is extremely conservative
when it comes to defining what standard library functions that have
side effects are required to do. The verbiage in C99 is as follows:

If the space cannot be allocated, a null pointer is
returned.

It does not say "If the space is unavailable", or "If memory is full",
or anything else, merely "if the space cannot be allocated."

Reread what I wrote. If it's not nearly identical to what you assert
then I don't understand.

... As I
said: it's a quality of implementation issue; a sufficiently poor
implementation may never be able to allocate exactly 23 bytes and
unwilling to allocate more than requested.

Again this is relevant to this discussion how ? The "mystring" code I
hacked earlier is an example where on one platform malloc(0) returning
different values on different platforms causing vastly different things
to happen being a portability issue. That's all. Code like this
exists. The point is that new has a more strict definition and hence it
will result in better code portability. It seems damn obvious to me,
why cant you see it.

... Such an implementation
would be conformant, even though it would likely have no users.

Again, so what ? The point is that code (bad or otherwise) exists such
that it works on one platform and not another because of THIS behaviour
of malloc which does not happen with new. That's all. If you think it
does not exist, see my code above. If you don't believe that anyone
would write code like that, get more experience.

The standard does continue on to describe what appears to be a special
case for malloc(0):

If the size of the space requested is zero, the behavior is
implementation-
defined: either a null pointer is returned, or the behavior is as if
the size
were some nonzero value, except that the returned pointer shall not
be used
to access an object.

Very nice. Rather a stupid thing to put in the standard IMHO.

However, on closer analysis both of these cases can be derived from
the general behaviour of malloc described elsewhere: 1. that
arithmetic on the returned pointer be limited to the half-open
interval [x, x+size), which is an empty interval when size is 0, and
2. that malloc may return NULL. Therefore this is not a special case,
and implementations that return NULL on malloc(0) even when memory is
available are merely poor implementations.

Poor but compliant making the fault that of the standard.

Isn't it time to get these implementations fixed, Gianni?

Sure. By that question do you imply you want me to do something about
it? You seem to have a grasp of the issue, you're just as qualified as
I am. Good luck with the C committee.