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

[Neo]

"Lawrence Kirby" <lk****@netacti ve.co.uk> wrote in message
news:pa******** *************** *****@netactive .co.uk...

On Wed, 17 Nov 2004 15:49:10 +0530, Ravi Uday wrote:

"Neo" <ti************ ***@yahoo.com> wrote in message
news:30******** *****@uni-berlin.de...

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)
Get rid of the cast. The compiler should then complain, which is
good because the code is broken. Adding the cast doesn't fix the
code, it just stops the compiler complaining about the problem.

The problem is that you don't have a valid declaration for malloc()
in scope when you call it. In that case the compiler assumes
that malloc() returns int, but it doesn't, it returns void *. All
standard library functions are provided with a declaration in
the appropriate standard header. For malloc() that is <stdlib.h>.

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???
Your code invokes undefined behaviour due to the invalid cast, so anything
can happen. Once that's fixed the issue is as below i.e. the compiler does
it because the standard says it can.

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);
???

-Neo

See what the standard says

4.10.3 Memory management functions:

If the size of the space requested is zero, the behavior is
*implementation-defined*; the value returned shall be either a null
pointer or a unique pointer.

So check in your impelementation documents for answer !

Lawrence

[E. Robert Tisdale]

Neo wrote:

I've a simple qestion related to dynamic memory allocation in C.
[snip]
cat main.c #include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {

char *p = (char*)malloc(0 );

if(NULL == p)
printf("NULL\n" );
else
printf("Valid Pointer\n");

printf("*((int* )p - 1) = %d\n", *((int*)p - 1));
printf("p = %p\n", p);
return EXIT_SUCCESS;
}
gcc -Wall -std=c99 -pedantic -o main main.c
./main Valid Pointer
*((int*)p - 1) = 17
p = 0x9876008

My implementation allocates at least two
double word aligned double words
and returns a pointer to the second double word.
Why this code fragment returns a valid pointer to a memory block?

Because it can.

[pete]

Neo wrote:

#include <stdio.h> if( (p=(char*)mallo c(0)) == NULL)

isnt it a standard
practice to cast the pointer returned by the malloc() to desired type?

No.
It's a mistake that people make when they neglect to include stdlib.h,
and the compiler consequently warns them that malloc is returning
type int and needs to be cast.
Add
#include <stdlib.h>
and drop the cast.

--
pete

[Method Man]

"Lawrence Kirby" <lk****@netacti ve.co.uk> wrote in message
news:pa******** *************** *****@netactive .co.uk...

On Wed, 17 Nov 2004 07:45:50 -0500, Method Man wrote:
...

<OT>

Why didn't they put it in the standard that a null pointer must be returned? It seems like the right/logical behaviour for calling malloc on size 0 and avoids any confusion.

</OT>

Probably because there were existing implementations for both types of
result. I don't think it makes much practical difference, I can only think
of 2 uses for this:

1. Creating a unique pointer value which compares unequal to all others.
For this to work you would need to prefer the non-null return behaviour.
Of course you can use malloc(1) for this. However malloc() can always fail
so it could return null for any call.

Fair enough. Although, 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.

[Neo]

Right, thnx. for pointing it out.
its workin perfect!
-Neo

"pete" <pf*****@mindsp ring.com> wrote in message
news:41******** ***@mindspring. com...

Neo wrote:

>>> #include <stdio.h> >>> if( (p=(char*)mallo c(0)) == NULL)

isnt it a standard
practice to cast the pointer returned by the malloc() to desired type?

No.
It's a mistake that people make when they neglect to include stdlib.h,
and the compiler consequently warns them that malloc is returning
type int and needs to be cast.
Add
#include <stdlib.h>
and drop the cast.

--
pete

[Joona I Palaste]

Method Man <a@b.c> scribbled the following:

"Lawrence Kirby" <lk****@netacti ve.co.uk> wrote in message
news:pa******** *************** *****@netactive .co.uk...

On Wed, 17 Nov 2004 07:45:50 -0500, Method Man wrote:

> <OT>
>
> Why didn't they put it in the standard that a null pointer must be returned? > It seems like the right/logical behaviour for calling malloc on size 0 and > avoids any confusion.
>
> </OT>
Probably because there were existing implementations for both types of
result. I don't think it makes much practical difference, I can only think
of 2 uses for this:

1. Creating a unique pointer value which compares unequal to all others.
For this to work you would need to prefer the non-null return behaviour.
Of course you can use malloc(1) for this. However malloc() can always fail
so it could return null for any call.

Fair enough. Although, 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.

If the C memory model was continuous rather than discrete, then there
would be no problem. In a continuous memory model, pointer values would
only serve as "starting points" of allocated memory, not allocated
memory itself. If you think of the conventional discrete memory model as
labelling boxes with addresses, in a continuous memory model you don't
label the boxes, you label the gaps between them. This way the malloc()
implementation could safely return the same, non-null, pointer value
over and over again from calls to malloc(0), because reserving 0 bytes
onward from that gap between boxes doesn't actually reserve any box at
all, and it's the boxes you store stuff in, not the gaps between them.
This is of course very much off-topic for comp.lang.c but those who
have studied real analysis and topology know what I'm talking about.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante

[Dan Pop]

In <5g************ ******@read1.cg ocable.net> "Method Man" <a@b.c> writes:

"Lawrence Kirby" <lk****@netacti ve.co.uk> wrote in message
news:pa******* *************** ******@netactiv e.co.uk...

On Wed, 17 Nov 2004 07:45:50 -0500, Method Man wrote:
...

> <OT>
>
> Why didn't they put it in the standard that a null pointer must bereturned? > It seems like the right/logical behaviour for calling malloc on size 0and > avoids any confusion.
>
> </OT>
Probably because there were existing implementations for both types of
result. I don't think it makes much practical difference, I can only think
of 2 uses for this:

1. Creating a unique pointer value which compares unequal to all others.
For this to work you would need to prefer the non-null return behaviour.
Of course you can use malloc(1) for this. However malloc() can always fail
so it could return null for any call.

Fair enough. Although, I can't immediately see a practical use in obtaining
a valid pointer from malloc(0).

It's a "cheap" method for generating unique IDs.
I would be curious to know how the
implementati on handled dereferencing and type-casting for this magical
pointer.

The pointer is as ordinary as you can get. Dereferencing it invokes
undefined behaviour and conversions work as for other pointers. As
Lawrence told you, if you need this particular behaviour, just use the
following wrapper for malloc:

void *xmalloc(size_t size)
{
if (size == 0) size = 1;
return malloc(size);
}

And if you need the other behaviour, you can trivially get it from:

void *ymalloc(size_t size)
{
if (size == 0) return NULL;
return malloc(size);
}

Or, if you prefer macros:

#define XMALLOC(size) malloc(size == 0 ? 1 : size)
#define YMALLOC(size) (size == 0 ? NULL : malloc(size))

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

[Craig Barkhouse]

"Dan Pop" <Da*****@cern.c h> wrote in message
news:cn******** **@sunnews.cern .ch...

In <5g************ ******@read1.cg ocable.net> "Method Man" <a@b.c> writes:

Fair enough. Although, I can't immediately see a practical use in
obtaining
a valid pointer from malloc(0).

It's a "cheap" method for generating unique IDs.

Are successive calls to malloc(0) guaranteed to return unique values,
though? (Assuming they don't return NULL.) Given that actually
dereferencing such the pointer invokes undefined behaviour, couldn't a
malloc() implementation set aside a certain value that it always returns
when size is 0? It might have to increment a reference count that would
later get decremented by free().

[Richard Bos]

"Craig Barkhouse" <ca******@stude nt.cs.uwaterloo .ca> wrote:

Are successive calls to malloc(0) guaranteed to return unique values,
though? (Assuming they don't return NULL.) Given that actually
dereferencing such the pointer invokes undefined behaviour, couldn't a
malloc() implementation set aside a certain value that it always returns
when size is 0?

In C89, it isn't perfectly clear; the text says that

# If the space cannot be allocated, a null pointer is returned.
# If the size of the space requested is zero, the behavior is
# implementation-defined; the value returned shall be either a null
# pointer or a unique pointer.

without clarifying whether that means a pointer unique to zero-sized
malloc()s, or a unique pointer for _each_ zero-sized malloc().

In C99, this has been changed to

# 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.

Since

# Each such allocation shall yield a pointer to an object disjoint from
# any other object.

this means that in C99, each zero-sized malloc() must return a distinct
pointer (or a null pointer), and I think that with this knowledge, it's
clear that this was what was meant in C89, too.

Richard

[Ben Pfaff]

"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.
What problem do you envision with type-casting it?
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless