malloc(0)

[john smith]

Can someone please explain to me what is happening when I do a malloc(0).

This is what I did.

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

Then I printed the value of p and of course it was non-null.

But has it allocated memory or what?

I would think that it would return a null.

So, can someone please explain what is going on?

Many thanks.

[Victor Bazarov]

Re: malloc(0)

"john smith" <princetonharva rd@charter.net> wrote...[color=blue]
> Can someone please explain to me what is happening when I do a malloc(0).
>
> This is what I did.
>
> int* p = (int*)malloc(0) ;
>
> Then I printed the value of p and of course it was non-null.
>
> But has it allocated memory or what?
>
> I would think that it would return a null.
>
> So, can someone please explain what is going on?[/color]

The behaviour of 'malloc' (and 'calloc' and 'realloc') when the size
passed in is zero is implementation-defined (so RTFM) and can be
either of two: the return value is a null pointer or it is non-null
(as if the size is non-zero), but the pointer cannot be used to access
an object.

Victor

[Derrick Coetzee]

Re: malloc(0)

john smith wrote:[color=blue]
> int* p = (int*)malloc(0) ;
>
> But has it allocated memory or what? I would think that it would return a null.[/color]

It has indeed. It has allocated a block containing no bytes at all.
According to the C++ standard, malloc() is the same as in C, and
the comp.lang.c FAQ says:

11.26: What should malloc(0) do? Return a null pointer or a pointer to
0 bytes?

A: The ANSI/ISO Standard says that it may do either; the behavior
is implementation-defined (see question 11.33).

References: ISO Sec. 7.10.3; PCS Sec. 16.1 p. 386.
--
Derrick Coetzee
I grant this newsgroup posting into the public domain. I disclaim all
express or implied warranty and all liability. I am not a professional.

[Kai-Uwe Bux]

Re: malloc(0)

john smith wrote:
[color=blue]
> Can someone please explain to me what is happening when I do a malloc(0).
>
> This is what I did.
>
> int* p = (int*)malloc(0) ;
>
> Then I printed the value of p and of course it was non-null.
>
> But has it allocated memory or what?
>[/color]

Sure, it has allocated a block of length 0. I have no idea what you want to
do with a block that small, but I am sure that malloc has just allocated a
block of that size, after all that is what malloc is supposed to do
according to its man page.

[color=blue]
> I would think that it would return a null.[/color]

Why? It returns the location in memory where the allocated block starts.
That this block has *length* 0 does not imply that it should start at the
*location* 0.
[color=blue]
>
> So, can someone please explain what is going on?
>[/color]

Nothing is going on: allocating a block of length 0 is pretty useless as
you can store nothing in there. Yet, be sure to free it once you have no
need for it anymore.

[color=blue]
> Many thanks.[/color]



Best

Kai-Uwe Bux

[E. Robert Tisdale]

Re: malloc(0)

Victor Bazarov wrote:
[color=blue]
> john smith wrote:
>[color=green]
>>Can someone please explain to me what is happening when I do a malloc(0).
>>
>>This is what I did.
>>
>> int* p = (int*)malloc(0) ;
>>
>>Then I printed the value of p and of course it was non-null.
>>
>>But has it allocated memory or what?
>>
>>I would think that it would return a null.
>>
>>So, can someone please explain what is going on?[/color]
>
> The behaviour of 'malloc' (and 'calloc' and 'realloc')
> when the size passed in is zero is implementation-defined (so RTFM)
> and can be either of two:
> the return value is a null pointer or it is non-null
> (as if the size is non-zero),
> but the pointer cannot be used to access an object.[/color]
[color=blue]
> cat main.cc[/color]
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
if (1 < argc) {
const
size_t n = atoi(argv[1]);
int* p = (int*)malloc(n* sizeof(int));
fprintf(stdout, "%d = p[-1]\t", p[-1]);

for (size_t j = 0; j < 4; ++j)
p[j] = j;

for (size_t j = 0; j < 4; ++j)
fprintf(stdout, "%d = p[%d]\t", p[j], j);
fprintf(stdout, "\n");

}
return EXIT_SUCCESS;
}
[color=blue]
> g++ -Wall -ansi -pedantic -o main main.cc
> ./main 0[/color]
17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=blue]
>. /main 1[/color]
17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=blue]
> ./main 2[/color]
17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=blue]
> ./main 3[/color]
17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=blue]
> ./main 4[/color]
25 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3]

[Kai-Uwe Bux]

Re: malloc(0)

E. Robert Tisdale wrote:
[color=blue]
> Victor Bazarov wrote:
>[color=green]
>> john smith wrote:
>>[color=darkred]
>>>Can someone please explain to me what is happening when I do a malloc(0).
>>>
>>>This is what I did.
>>>
>>>int* p = (int*)malloc(0) ;
>>>
>>>Then I printed the value of p and of course it was non-null.
>>>
>>>But has it allocated memory or what?
>>>
>>>I would think that it would return a null.
>>>
>>>So, can someone please explain what is going on?[/color]
>>
>> The behaviour of 'malloc' (and 'calloc' and 'realloc')
>> when the size passed in is zero is implementation-defined (so RTFM)
>> and can be either of two:
>> the return value is a null pointer or it is non-null
>> (as if the size is non-zero),
>> but the pointer cannot be used to access an object.[/color]
>[color=green]
> > cat main.cc[/color]
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char* argv[]) {
> if (1 < argc) {
> const
> size_t n = atoi(argv[1]);
> int* p = (int*)malloc(n* sizeof(int));
> fprintf(stdout, "%d = p[-1]\t", p[-1]);
>
> for (size_t j = 0; j < 4; ++j)
> p[j] = j;
>
> for (size_t j = 0; j < 4; ++j)
> fprintf(stdout, "%d = p[%d]\t", p[j], j);
> fprintf(stdout, "\n");
>
> }
> return EXIT_SUCCESS;
> }
>[color=green]
> > g++ -Wall -ansi -pedantic -o main main.cc
> > ./main 0[/color]
> 17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=green]
> >. /main 1[/color]
> 17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=green]
> > ./main 2[/color]
> 17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=green]
> > ./main 3[/color]
> 17 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][color=green]
> > ./main 4[/color]
> 25 = p[-1] 0 = p[0] 1 = p[1] 2 = p[2] 3 = p[3][/color]

And your point is?

I guess, you wrote a program whose behavior is undefined; and you happend
to get away with it this time for a particular implementation.

#include <cstdlib>
#include <iostream>

struct xxx {
char banner [26];
};

int main( void ) {
xxx* p = (xxx*)malloc(0* sizeof(xxx));
xxx* q = (xxx*)malloc(0* sizeof(xxx));

std::strcpy( p->banner, "Hello folks, how are you?" );
std::strcpy( q->banner, "Hello folks, how are you?" );

std::cout << "p->banner: " << p->banner << "\n";
std::cout << "q->banner: " << q->banner << "\n";

return 0;
}
[color=blue]
> g++ scratch.cc
> a.out[/color]
p->banner: Hello folks, howHello folks, how are you?
q->banner: Hello folks, how are you?



Best

Kai-Uwe Bux

[E. Robert Tisdale]

Re: malloc(0)

Kai-Uwe Bux wrote:
[color=blue]
> I guess, you wrote a program whose behavior is undefined;
> and you happend to get away with it this time
> for a particular implementation.
>
> #include <cstdlib>
> #include <iostream>
>
> struct xxx {
> char banner [26];
> };
>
> int main( void ) {
> xxx* p = (xxx*)malloc(0* sizeof(xxx));
> xxx* q = (xxx*)malloc(0* sizeof(xxx));
>
> std::strcpy( p->banner, "Hello folks, how are you?" );
> std::strcpy( q->banner, "Hello folks, how are you?" );
>
> std::cout << "p->banner: " << p->banner << "\n";
> std::cout << "q->banner: " << q->banner << "\n";
>
> return 0;
> }
>[color=green]
>>g++ scratch.cc
>>a.out[/color]
>
> p->banner: Hello folks, howHello folks, how are you?
> q->banner: Hello folks, how are you?[/color]

You should always free storage that you allocate:
[color=blue]
> cat scratch.cc[/color]
#include <cstdlib>
#include <iostream>

typedef struct xxx {
char banner [26];
} xxx;

int main(int argc, char* argv[]) {
xxx* p = (xxx*)malloc(0* sizeof(xxx));
xxx* q = (xxx*)malloc(0* sizeof(xxx));

std::strcpy( p->banner, "Hello folks, how are you?" );
std::strcpy( q->banner, "Hello folks, how are you?" );

std::cout << "p->banner: " << p->banner << "\n";
std::cout << "q->banner: " << q->banner << "\n";

free((void*)q);
free((void*)p);

return EXIT_SUCCESS;
}
[color=blue]
> g++ -Wall -ansi -pedantic -o scratch scratch.cc
> ./scratch[/color]
p->banner: Hello folks, howHello folks, how are you?
q->banner: Hello folks, how are you?
Segmentation fault (core dumped)

[Kai-Uwe Bux]

Re: malloc(0)

E. Robert Tisdale wrote:
[color=blue]
> Kai-Uwe Bux wrote:
>[color=green]
>> I guess, you wrote a program whose behavior is undefined;
>> and you happend to get away with it this time
>> for a particular implementation.
>>
>> #include <cstdlib>
>> #include <iostream>
>>
>> struct xxx {
>> char banner [26];
>> };
>>
>> int main( void ) {
>> xxx* p = (xxx*)malloc(0* sizeof(xxx));
>> xxx* q = (xxx*)malloc(0* sizeof(xxx));
>>
>> std::strcpy( p->banner, "Hello folks, how are you?" );
>> std::strcpy( q->banner, "Hello folks, how are you?" );
>>
>> std::cout << "p->banner: " << p->banner << "\n";
>> std::cout << "q->banner: " << q->banner << "\n";
>>
>> return 0;
>> }
>>[color=darkred]
>>>g++ scratch.cc
>>>a.out[/color]
>>
>> p->banner: Hello folks, howHello folks, how are you?
>> q->banner: Hello folks, how are you?[/color]
>
> You should always free storage that you allocate:[/color]
^^^^^^

Why?

In the case under discussion, the operating system will reclaim all
allocated memory since the program is about to die anyway. I do see no
point in freeing the memory myself.


Best

Kai-Uwe Bux
[color=blue]
>[color=green]
> > cat scratch.cc[/color]
> #include <cstdlib>
> #include <iostream>
>
> typedef struct xxx {
> char banner [26];
> } xxx;
>
> int main(int argc, char* argv[]) {
> xxx* p = (xxx*)malloc(0* sizeof(xxx));
> xxx* q = (xxx*)malloc(0* sizeof(xxx));
>
> std::strcpy( p->banner, "Hello folks, how are you?" );
> std::strcpy( q->banner, "Hello folks, how are you?" );
>
> std::cout << "p->banner: " << p->banner << "\n";
> std::cout << "q->banner: " << q->banner << "\n";
>
> free((void*)q);
> free((void*)p);
>
> return EXIT_SUCCESS;
> }
>[color=green]
> > g++ -Wall -ansi -pedantic -o scratch scratch.cc
> > ./scratch[/color]
> p->banner: Hello folks, howHello folks, how are you?
> q->banner: Hello folks, how are you?
> Segmentation fault (core dumped)[/color]

[Gianni Mariani]

Re: malloc(0)

Kai-Uwe Bux wrote:[color=blue]
> E. Robert Tisdale wrote:[/color]
.....[color=blue]
>
> Why?
>
> In the case under discussion, the operating system will reclaim all
> allocated memory since the program is about to die anyway. I do see no
> point in freeing the memory myself.[/color]

While in this particular scenario, you're right, in practice this is the
exception. Since this is an example, it should demonstrate the more
general scenario and hence why free() should be called.

[Jerry Coffin]

Re: malloc(0)

"john smith" <princetonharva rd@charter.net> wrote in message news:<10jksptg5 12qa8d@corp.sup ernews.com>...[color=blue]
> Can someone please explain to me what is happening when I do a malloc(0).
>
> This is what I did.
>
> int* p = (int*)malloc(0) ;
>
> Then I printed the value of p and of course it was non-null.
>
> But has it allocated memory or what?
>
> I would think that it would return a null.[/color]

Using malloc with an argument of 0 gives implementation-defined
results -- it can return a null pointer or it can return a non-null
pointer to a block that you can't dereference.

As an aside, using new instead of malloc would give a non-null pointer
that you can't dereference (or more accurately, attempting to
dereference it would give undefined behavior).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jack Klein]

Re: malloc(0)

On Sun, 05 Sep 2004 02:27:08 -0400, Kai-Uwe Bux <jkherciueh@gmx .net>
wrote in comp.lang.c++:
[color=blue]
> E. Robert Tisdale wrote:[color=green]
> > You should always free storage that you allocate:[/color]
> ^^^^^^
>
> Why?
>
> In the case under discussion, the operating system will reclaim all
> allocated memory since the program is about to die anyway. I do see no
> point in freeing the memory myself.[/color]

Much as I dislike agreeing with the troll Tisdale, he is perfectly
correct here.

Exactly where in the C++ standard does it state that allocated memory
not released by a program will be reclaimed by the operating system?
Where is the guarantee that this works on all implementations and all
platforms?

And of course what happens when someone tries to reuse the code inside
a larger program by renaming main()?

Sloppy programming habits should never be encouraged. Or even
tolerated.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[Jack Klein]

Re: malloc(0)

On Sat, 04 Sep 2004 22:50:25 -0400, Kai-Uwe Bux <jkherciueh@gmx .net>
wrote in comp.lang.c++:
[color=blue]
> john smith wrote:
>[color=green]
> > Can someone please explain to me what is happening when I do a malloc(0).
> >
> > This is what I did.
> >
> > int* p = (int*)malloc(0) ;
> >
> > Then I printed the value of p and of course it was non-null.
> >
> > But has it allocated memory or what?
> >[/color]
>
> Sure, it has allocated a block of length 0. I have no idea what you want to
> do with a block that small, but I am sure that malloc has just allocated a
> block of that size, after all that is what malloc is supposed to do
> according to its man page.[/color]

That is one of the two defined actions that malloc() may take. The
other is to return a null pointer.
[color=blue][color=green]
> > I would think that it would return a null.[/color]
>
> Why? It returns the location in memory where the allocated block starts.
> That this block has *length* 0 does not imply that it should start at the
> *location* 0.[/color]

What do you think that a null pointer has to do with location 0? A
null pointer does not point to location 0. It does not even have an
all-bits zero representation on all platforms.

If there is a location 0 on a platform and it is valid for a C (or
C++) object to reside there, then a pointer to such an object would be
a pointer to location 0 and it would most specifically not be a null
pointer.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[David Hilsee]

Re: malloc(0)

"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:che7lm$iji $1@nntp1.jpl.na sa.gov...[color=blue]
> Kai-Uwe Bux wrote:
>[color=green]
> > I guess, you wrote a program whose behavior is undefined;
> > and you happend to get away with it this time
> > for a particular implementation.
> >
> > #include <cstdlib>
> > #include <iostream>
> >
> > struct xxx {
> > char banner [26];
> > };
> >
> > int main( void ) {
> > xxx* p = (xxx*)malloc(0* sizeof(xxx));
> > xxx* q = (xxx*)malloc(0* sizeof(xxx));
> >
> > std::strcpy( p->banner, "Hello folks, how are you?" );
> > std::strcpy( q->banner, "Hello folks, how are you?" );
> >
> > std::cout << "p->banner: " << p->banner << "\n";
> > std::cout << "q->banner: " << q->banner << "\n";
> >
> > return 0;
> > }
> >[color=darkred]
> >>g++ scratch.cc
> >>a.out[/color]
> >
> > p->banner: Hello folks, howHello folks, how are you?
> > q->banner: Hello folks, how are you?[/color]
>
> You should always free storage that you allocate:[/color]
<snip>

You didn't free the storage in your original example, either. What happens
when you "correct" it?

--
David Hilsee

[Kai-Uwe Bux]

Re: malloc(0)

Jack Klein wrote:
[color=blue]
> On Sat, 04 Sep 2004 22:50:25 -0400, Kai-Uwe Bux <jkherciueh@gmx .net>
> wrote in comp.lang.c++:
>[color=green]
>> john smith wrote:
>>[color=darkred]
>> > Can someone please explain to me what is happening when I do a
>> > malloc(0).
>> >
>> > This is what I did.
>> >
>> > int* p = (int*)malloc(0) ;
>> >
>> > Then I printed the value of p and of course it was non-null.
>> >
>> > But has it allocated memory or what?
>> >[/color]
>>
>> Sure, it has allocated a block of length 0. I have no idea what you want
>> to do with a block that small, but I am sure that malloc has just
>> allocated a block of that size, after all that is what malloc is supposed
>> to do according to its man page.[/color]
>
> That is one of the two defined actions that malloc() may take. The
> other is to return a null pointer.[/color]

Actually, I was completely wrong, but maybe notin the way you may have had
in mind primarily.

As far as I can tell from the standard, which I have read now, every call
to malloc, regardless of the argument, may return a null pointer any time.
As far as I can see, the standard makes no guarantees that calls to malloc
"succeed". So there is no difference between malloc(0) and malloc(n). The
standard just allows explicitly that every call malloc(0) may fail,
however, I cannot see that it does not allow that for other values too. In
fact, I do not see any language in the standard that would rule out the
following most useless implementation:

void* malloc( size_t size ) {
return( NULL );
}


Besides, the OP explictly mentioned that malloc(0) did not return 0 and
asked what was going on. So, I was describing what happens for a succesful
call to malloc(0), and I was mistaken on a subtle point. I thought,
incorrectly, that malloc(0) had allocated a chunk of size 0. In particular,
I thought that subsequent calls to malloc(0) may return the same pointer.
That, however, may not be allowed:

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.

Thus, if malloc(0) does not return 0, it shall behave as though it was
called with a non-zero argument. I read this to imply that two successive
calls to malloc(0), neither of which returns 0, must return different
values. This is an extra requirement that would not otherwise follow from
the usual requirement that allocated blocks are to be disjoint.

[color=blue][color=green][color=darkred]
>> > I would think that it would return a null.[/color]
>>
>> Why? It returns the location in memory where the allocated block starts.
>> That this block has *length* 0 does not imply that it should start at the
>> *location* 0.[/color]
>
> What do you think that a null pointer has to do with location 0? A
> null pointer does not point to location 0. It does not even have an
> all-bits zero representation on all platforms.
>
> If there is a location 0 on a platform and it is valid for a C (or
> C++) object to reside there, then a pointer to such an object would be
> a pointer to location 0 and it would most specifically not be a null
> pointer.
>[/color]

You are right, I was sloppy.

Just an asside triggered by your remark: is the numerical constant 0 (say
as an int or unsigned int) required to have an all-bits zeror
epresentation?


Best

Kai-Uwe Bux

[Kai-Uwe Bux]

Re: malloc(0)

Jack Klein wrote:
[color=blue]
> On Sun, 05 Sep 2004 02:27:08 -0400, Kai-Uwe Bux <jkherciueh@gmx .net>
> wrote in comp.lang.c++:
>[color=green]
>> E. Robert Tisdale wrote:[color=darkred]
>> > You should always free storage that you allocate:[/color]
>> ^^^^^^
>>
>> Why?
>>
>> In the case under discussion, the operating system will reclaim all
>> allocated memory since the program is about to die anyway. I do see no
>> point in freeing the memory myself.[/color]
>
> Much as I dislike agreeing with the troll Tisdale, he is perfectly
> correct here.
>
> Exactly where in the C++ standard does it state that allocated memory
> not released by a program will be reclaimed by the operating system?
> Where is the guarantee that this works on all implementations and all
> platforms?
>[/color]

Interesting question, however, your concern will not be cured by the call
to free() that was proposed. From the C standard:

The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation. ...

Since this part is inherited by C++, and since C++ does only specify the
observable behavior of a single instruction sequence, the phrase "available
for further allocation" just refers to the very C++ programm that is
calling free(), i.e, subsequence calls to malloc() or new() may now return
this memory. There is, as far as I can see, no gurantee whatsoever in the C
or C++ standard that space deallocated by free() or delete() is returned to
the operating system (thereby becomming available to *other programs*)?

Where do you get your guarantee that freeing memory works as you seem to
expect?

[color=blue]
> And of course what happens when someone tries to reuse the code inside
> a larger program by renaming main()?
>
> Sloppy programming habits should never be encouraged. Or even tolerated.[/color]

My understanding of sloppyness is something along the lines of "not
thinking about what I code". I question rules that contain the word
"always" or "never" because, more often than not, they encourage sloppyness
in this sense. For example, reusing main() by renaming without reading it
would be sloppy.

Besides, the example was meant to illustrate a point under discussion and
not teach how to programm -- it exhibits undefined behavior anyway.


Best

Kai-Uwe Bux