From the documentation of malloc(), malloc(0) should return NULL. But it
is not.
The following program I executed in my computer:
#include<stdlib.h>
main()
{
char *buf;
buf=(char *)malloc(0);
if(buf!=NULL)
{
printf(“Not NULL\n”);
free(buf);
}
else
printf(“Null\n”);
return 0;
}
The output I got is : Not NULL
What may be the reason ?
With Regards
Jitendra Sasmal
Perhaps, the caveat should also say, “POSIX says that on the passing of
a 0 value malloc() may either return NULL or may return a pointer
suitable for passing to the free() function.”
David Gibbs <dagibbs@qnx.com> wrote:
DG > Jitendra Sasmal <sasmal_jk@rediffmail.com> wrote:
From the documentation of malloc(), malloc(0) should return NULL. But it
is not.
DG > I tested it, though I did a printf of buf after the malloc – getting
DG > buf is 8051898
DG > The documentation for malloc() has an odd caveat:
DG > In QNX 4, nothing is allocated when you malloc() 0 bytes. Be
DG > careful if your code is ported between QNX 4 and QNX Neutrino.
DG > Which suggests that a malloc(0) is expected to allocate something
DG > under QNX Neutrino.
DG > According to the standards I looked into, most of them don’t specify,
DG > but POSIX says that on the passing of a 0 value malloc() may either
DG > return NULL or may return a pointer suitable for passing to the
DG > free() function.
DG > So, I think the docs are wrong.
DG > -David
Jitendra Sasmal <sasmal_jk@rediffmail.com> wrote:
From the documentation of malloc(), malloc(0) should return NULL. But it
is not.
I tested it, though I did a printf of buf after the malloc – getting
buf is 8051898
The documentation for malloc() has an odd caveat:
In QNX 4, nothing is allocated when you malloc() 0 bytes. Be
careful if your code is ported between QNX 4 and QNX Neutrino.
Which suggests that a malloc(0) is expected to allocate something
under QNX Neutrino.
According to the standards I looked into, most of them don’t specify,
but POSIX says that on the passing of a 0 value malloc() may either
return NULL or may return a pointer suitable for passing to the
free() function.
So, I think the docs are wrong.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
So, I think the docs are wrong.
PR 17991 to fix malloc() docs. I think the Returns: section should read:
Returns:
A pointer to the start of the allocated memory, or NULL if an
error occurred (errno is set).
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote in message
news:br4s31$k13$1@nntp.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
So, I think the docs are wrong.
PR 17991 to fix malloc() docs. I think the Returns: section should read:
Returns:
A pointer to the start of the allocated memory, or NULL if an
error occurred (errno is set).
Add to that:
a malloc of size 0 is ambiguous and while a valid/unique pointer is
returned, the user cannot assume that it is actually pointing to valid user
memory.
-Adam
“Adam Mallory” <amallory@qnx.com> wrote in message
news:br5j2e$dlt$1@nntp.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote in message
news:br4s31$k13$> 1@nntp.qnx.com> …
David Gibbs <> dagibbs@qnx.com> > wrote:So, I think the docs are wrong.
PR 17991 to fix malloc() docs. I think the Returns: section should
read:Returns:
A pointer to the start of the allocated memory, or NULL if an
error occurred (errno is set).Add to that:
a malloc of size 0 is ambiguous and while a valid/unique pointer is
returned, the user cannot assume that it is actually pointing to valid
user
memory.
A little confusing, I would think. Naturally if you malloc’ed zero bytes,
the
user area of the block may be no more than zero bytes, so the only thing
that can safely be done with it is free(). That’s simply a direct logical
consequence,
though, and shouldn’t require further attempts to clarify it (with language
that
may add to any confusion).
-Adam
Steve Furr <furr@qnx.com> wrote in message news:br5jc9$e2p$1@nntp.qnx.com…
A little confusing, I would think. Naturally if you malloc’ed zero bytes,
the
user area of the block may be no more than zero bytes, so the only thing
that can safely be done with it is free(). That’s simply a direct logical
consequence,
though, and shouldn’t require further attempts to clarify it (with
language
that
may add to any confusion).
No - nothing about malloc() says the size you ask for is the size of the
user area. The size specified is a minimum and nothing more.
-Adam
Adam Mallory <amallory@qnx.com> wrote:
Steve Furr <> furr@qnx.com> > wrote in message news:br5jc9$e2p$> 1@nntp.qnx.com> …
A little confusing, I would think. Naturally if you malloc’ed zero bytes,
the
user area of the block may be no more than zero bytes, so the only thing
that can safely be done with it is free(). That’s simply a direct logical
consequence,
though, and shouldn’t require further attempts to clarify it (with
language
that
may add to any confusion).No - nothing about malloc() says the size you ask for is the size of the
user area. The size specified is a minimum and nothing more.
Actually, that’s what Steve said…
“the user area of the block may be no more than zero bytes”
Though, I could see two different ways of reading that…
“the user area of the block is not allowed to be more than zero bytes”
(which is how I think you read it)
and
“the user area of the block could be zero bytes”
(which is what I think Steve meant, and how I read it)
English is such a slippery language… imagine trying to program in it.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Adam Mallory <amallory@qnx.com> wrote:
Steve Furr <> furr@qnx.com> > wrote in message news:br5jc9$e2p$> 1@nntp.qnx.com> …
A little confusing, I would think. Naturally if you malloc’ed zero bytes,
the
user area of the block may be no more than zero bytes, so the only thing
that can safely be done with it is free(). That’s simply a direct logical
consequence,
though, and shouldn’t require further attempts to clarify it (with
language
that
may add to any confusion).No - nothing about malloc() says the size you ask for is the size of the
user area. The size specified is a minimum and nothing more.
The size specified is the number of bytes that the specs allow the
program to dereference. Internally, malloc() may know that the pointer
points to an area of memory that’s bigger than the program requested;
but personally, I think it’s misleading to call that bigger area the
“user area”. Especially if the discussion is about the specification of
malloc() rather than about internal details of one particular
implementation of malloc().
As far as the C and POSIX specs go, the area you get is exactly the size
you asked for. There may be bytes beyond what you asked for, but trying
to dereference them produces undefined behaviour. In particular, if you
asked for zero bytes, you cannot safely access any bytes.
OTOH, it’s not exactly true that the only thing you can do with a
pointer returned by malloc(0) is give it back to free(). You can also
compare it to other pointers. Since it’s guaranteed to be unique, this
might sometimes be useful.
As far as the C and POSIX specs go, the area you get is exactly the size
you asked for. There may be bytes beyond what you asked for, but trying
to dereference them produces undefined behaviour. In particular, if you
asked for zero bytes, you cannot safely access any bytes.OTOH, it’s not exactly true that the only thing you can do with a
pointer returned by malloc(0) is give it back to free(). You can also
compare it to other pointers. Since it’s guaranteed to be unique, this
might sometimes be useful.
If NULL is an acceptable return for malloc(0), how can it be guaranteed to
be unique?
bstecher@qnx.com wrote:
Marty Doane <> martin.doane@siemens.com> > wrote:
If NULL is an acceptable return for malloc(0), how can it be guaranteed to
be unique?You’re allowed to return NULL or a non-NULL value. If you return a
non-NULL value, it has to be different from all the other non-NULL value
that you’ve returned.
Except the ones that have been freed, of course.
Marty Doane <martin.doane@siemens.com> wrote:
As far as the C and POSIX specs go, the area you get is exactly the size
you asked for. There may be bytes beyond what you asked for, but trying
to dereference them produces undefined behaviour. In particular, if you
asked for zero bytes, you cannot safely access any bytes.OTOH, it’s not exactly true that the only thing you can do with a
pointer returned by malloc(0) is give it back to free(). You can also
compare it to other pointers. Since it’s guaranteed to be unique, this
might sometimes be useful.If NULL is an acceptable return for malloc(0), how can it be guaranteed to
be unique?
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Marty Doane <martin.doane@siemens.com> wrote:
OTOH, it’s not exactly true that the only thing you can do with a
pointer returned by malloc(0) is give it back to free(). You can also
compare it to other pointers. Since it’s guaranteed to be unique, this
might sometimes be useful.If NULL is an acceptable return for malloc(0), how can it be guaranteed to
be unique?
NULL is not; I was talking about the case where malloc(0) returns a
non-NULL pointer. Sorry if that wasn’t clear.