call to malloc with size 0

[Neo]

Hi Folks,

I've a simple qestion related to dynamic memory allocation in C here is the
code:

#include <stdio.h>

int main()

{

char *p;

if( (p=(char*)mallo c(0)) == NULL)

printf("NULL\n" );

else

printf("Valid Pointer\n");

return 0;

}

Output : "Valid Pointer"

Why this code fragment returns a valid pointer to a memory block???

-Neo

[Keith Thompson]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > writes:

Flash Gordon wrote:

Neo wrote:
<snip not casting the return value of malloc.

invalid cast - what do you mean by saying *invalid cast*. isnt it a
standard practice to cast the pointer returned by the malloc() to
desired type? or how then it can be otherwise like:
p = malloc(0);
???

In C, it is standard practice to not cast the value returned by malloc.
Nonsense!

No, it's not nonsense, as we've repeatedly explained at length.
There are a few obscure exceptions, and one person who posts here
has a good reason why he (as opposed to everyone else) has to.

Lots of people who post here have good rerasons
to cast the pointer returned by the malloc(size_t).

You claim to have a good reason, with no real justification that I've
seen. P.J. Plauger apparently does have a good reason; he needs to
write code that his customers can compile either as C or as C++. I
haven't seen anyone else make a coherent argument in favor of casting
the result of malloc().

[...]
Write:

char* p = (char*)malloc(n *sizeof(char*)) ;

and both C and C++ compilers will accept your code.

Write

char *p = malloc(n);

or

some_type *p = malloc(n * sizeof *p);

and use a C compiler. Or use a "new" operator and use a C++ compiler.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Herbert Rosenau]

On Fri, 19 Nov 2004 23:26:05 UTC, "E. Robert Tisdale"
<E.************ **@jpl.nasa.gov > wrote:

Write:

char* p = (char*)malloc(n *sizeof(char*)) ;

and both C and C++ compilers will accept your code.

Twitsdale is posting crap once again. Twitsdale is unable to learn C
as defined by the standard because he thinks ther is no other C
compiler as Wincrap existent on the real world.

Put twitsdale into your filters and you bewares yourself always of the
crap this bloody ignorant craps out of his ass.

There is really NO, absolutely NO reason to cast the result of a
function that returns a pointer to void. But here are thousend reasons
you invoke the lands of undefined behvior. When you writs C++ you have
in no ways a reason to use malloc() - new will always be better. When
you have to write C - use a C-compiler, when you have to write C++
then you have to use a C++-comiler.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation

[Herbert Rosenau]

On Thu, 18 Nov 2004 18:25:05 UTC, Ben Pfaff <bl*@cs.stanfor d.edu>
wrote:

"Method Man" <a@b.c> writes:

I can't immediately see a practical use in obtaining a valid
pointer from malloc(0). I would be curious to know how the
implementation handled dereferencing and type-casting for this
magical pointer.
Dereferencing the result of malloc(0) yields undefined behavior.

No, implementation defined behavior only.
What problem do you envision with type-casting it?

undefined behavior as always by casting a result of a function that
returns pointer to void and is called without prototype in sight.
Implemenation defined behavior can be tolerable - undefined behavior
is never.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation

[Ben Pfaff]

"Herbert Rosenau" <os****@pc-rosenau.de> writes:

On Thu, 18 Nov 2004 18:25:05 UTC, Ben Pfaff <bl*@cs.stanfor d.edu>
wrote:

"Method Man" <a@b.c> writes:

> I can't immediately see a practical use in obtaining a valid
> pointer from malloc(0). I would be curious to know how the
> implementation handled dereferencing and type-casting for this
> magical pointer.
Dereferencing the result of malloc(0) yields undefined behavior.

No, implementation defined behavior only.

Here is what the standard says:

If an invalid value has been assigned to the pointer, the
behavior of the unary * operator is undefined.83)

If malloc(0) returns a null pointer, then this is sufficient to
makes its behavior undefined. If malloc(0) return a non-null
pointer, then this quote from the standard holds:

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.

A violation of a "shall" requirement yields undefined behavior:

If a ``shall'' or ``shall not'' requirement that appears
outside of a constraint is violated, the behavior is
undefined.

Why do you think that dereferencing malloc(0) yields only
implementation-defined behavior?

What problem do you envision with type-casting it?

undefined behavior as always by casting a result of a function that
returns pointer to void and is called without prototype in sight.

I don't see how this is specific to malloc(0), and I don't see
that this is the issue at hand anyhow.
Implemenation defined behavior can be tolerable - undefined
behavior is never.

Only in programs intended to be completely portable.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming

[Joona I Palaste]

Herbert Rosenau <os****@pc-rosenau.de> scribbled the following:

On Fri, 19 Nov 2004 23:26:05 UTC, "E. Robert Tisdale"
<E.************ **@jpl.nasa.gov > wrote:

Write:

char* p = (char*)malloc(n *sizeof(char*)) ;

and both C and C++ compilers will accept your code.

Twitsdale is posting crap once again. Twitsdale is unable to learn C
as defined by the standard because he thinks ther is no other C
compiler as Wincrap existent on the real world. Put twitsdale into your filters and you bewares yourself always of the
crap this bloody ignorant craps out of his ass. There is really NO, absolutely NO reason to cast the result of a
function that returns a pointer to void. But here are thousend reasons
you invoke the lands of undefined behvior. When you writs C++ you have
in no ways a reason to use malloc() - new will always be better. When
you have to write C - use a C-compiler, when you have to write C++
then you have to use a C++-comiler.

Furthermore, Trollsdale used the wrong type in his sizeof operation.
The correct type would be what the pointer points at, not the pointer
type itself. sizeof *p would have worked much better.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran

[Spiro Trikaliotis]

Hello,

Herbert Rosenau <os****@pc-rosenau.de> schrieb:

When you writs C++ you have in no ways a reason to use malloc() - new
will always be better.

If I want to implement my own operator new, there are legit reasons to
call malloc on my own, even in C++.

But this is getting OT in this newsgroup here.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://www.viceteam.org/

[Mark McIntyre]

On Sat, 20 Nov 2004 23:26:21 +0000 (UTC), in comp.lang.c , "Herbert
Rosenau" <os****@pc-rosenau.de> wrote:

On Thu, 18 Nov 2004 18:25:05 UTC, Ben Pfaff <bl*@cs.stanfor d.edu>
wrote:

"Method Man" <a@b.c> writes:

> I can't immediately see a practical use in obtaining a valid
> pointer from malloc(0). I would be curious to know how the
> implementation handled dereferencing and type-casting for this
> magical pointer.

Dereferencing the result of malloc(0) yields undefined behavior.

No, implementation defined behavior only.

The return from malloc is implementation defined but must be either a null
pointer or an unusable pointer. Dereferencing either of those is undefined,
by definition....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Sun, 21 Nov 2004 11:46:27 +0100, in comp.lang.c , Spiro Trikaliotis
<ne*********@tr ikaliotis.net> wrote:

Hello,

Herbert Rosenau <os****@pc-rosenau.de> schrieb:

When you writs C++ you have in no ways a reason to use malloc() - new
will always be better.
If I want to implement my own operator new,

But this isn't writing in C++, this is writing a compiler... :-)
there are legit reasons to
call malloc on my own, even in C++.
If you want to implement your own operator new, you'd be better advised to
use processor-specific memory management primitives.
But this is getting OT in this newsgroup here.

indeed.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Charlie Gordon]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:cn******** **@nntp1.jpl.na sa.gov...

Write:

char* p = (char*)malloc(n *sizeof(char*)) ;

and both C and C++ compilers will accept your code.

Right : neither will catch that you don't get the difference between char and
char* !

A compromise solution :

#define MALLOC(count, type) ((type *)malloc((count ) * sizeof(type)))

and use it without a cast :

char *p = MALLOC(n, char);

that will work in both C and C++, and enforce consistency between allocation and
use.

Of course a compiler that does not complain about calling a function without
proper prototype is either broken or misconfigured. Fix that first.

Chqrlie.

[Dan Pop]

In <92************ @brenda.flash-gordon.me.uk> Flash Gordon <sp**@flash-gordon.me.uk> writes:

On Fri, 19 Nov 2004 01:11:17 GMT
Keith Thompson <ks***@mib.or g> wrote:

Da*****@cern.ch (Dan Pop) writes:
[...]

> Or, if you prefer macros:
>
> #define XMALLOC(size) malloc(size == 0 ? 1 : size)
> #define YMALLOC(size) (size == 0 ? NULL : malloc(size))

Your XMALLOC is probably clearer than the one I came up with, but I'm
going to show it off because I think it's kinda clever.

#define XMALLOC(size) malloc((size) + ((size)==0))

(Yes, I habitually parenthesize references to arguments to
function-like macros; it's easier than figuring out when it isn't
necessary.)

Of course, either macro is a potential problem if you do
p = XMALLOC( size_array[i++] );

The names are spelled in upper case to warn the user that they're macros,
not functions. If the user chooses to ignore the warnings, he gets
exactly what he deserves.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union