"free" deallocation function with VisualDSP++ 4.5 for BF

In article <aOMBh.76860$qO4.48404@newssvr13.news.prodigy.net>, Vladimir 
Vassilevsky says...
> 
> 
> Jack Klein wrote:
> 
> > The recognition of "0", "NULL", or "(void *)0" as a null pointer
> > constant in C and C++ is a compile time feature, and says nothing at
> > all about the binary representation of the actual null pointer value.
> > It is similar in that respect to the way the compiler recognizes "\n"
> > at compile time in a quoted string and replaces those two characters
> > with whatever newline is (usually 0x10, ASCII line feed) on the
> > platform.
> 
> It is nice in the theory, however can you give an example of a compiter 
> and an architecture, where the NULL pointer does not have the binary 
> value of zero?

Apparently

http://www.lysator.liu.se/c/c-faq/c-1.html

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

On Sat, 17 Feb 2007 16:04:16 -0600, Vladimir Vassilevsky
<antispam_bogus@hotmail.com> wrote:

>The peculiarity of BlackFin is that 0x00000000 can be a perfectly valid 
>address. For that reason it would make sense to redefine NULL as 
>0xFFFFFFFF, for example. That can be done in C; however the C++ 
>convention requres NULL == 0.

Since free() does not contain an argument specifying the size of the
area to be deallocated, the run-time library must at least keep track
of the _actual_ allocation size during malloc. Some other bookkeeping
information may also be saved during malloc.

At least some compilers save this data just below the pointer
returned. Even if the dynamic memory starts at 0x00000000 and the heap
is empty, calling malloc(7) might actually allocate the first 12 bytes
from dynamic memory, storing the length at 0x00000000, malloc would
return a pointer to 0x00000004 and leaving the last byte unused, so
that the next allocation would start at the next longword boundary at
0x0000000C. 

Thus, calling free(0x0000004) would not be a problem.

Even if the bookkeeping info is stored separately, there would not be
a necessity to start the first allocation at zero, since a dummy
variable could be placed at 0x00000000, forcing the first dynamic
allocation to start from 0x00000004. 

The only real use for a 0x00000000 pointer would be if the hardware
contains some memory mapped peripheral registers at 0x00000000, but
why would you call free() for such pointers anyway. If the RTL knows
about the memory mapping to registers, it could simply discard any
free() requests to the memory mapped peripheral area.

Paul