Reply by Paul Keinanen●February 18, 20072007-02-18
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
Reply by Robert Adsett●February 17, 20072007-02-17
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?
Reply by Vladimir Vassilevsky●February 17, 20072007-02-17
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?
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Reply by Jack Klein●February 17, 20072007-02-17
On Sat, 17 Feb 2007 16:04:16 -0600, Vladimir Vassilevsky
<antispam_bogus@hotmail.com> wrote in comp.arch.embedded:
>
>
> Hans-Bernhard Br�ker wrote:
>
> >> So, if NULL (0x0000 0000) is not created when a pointer is declared
> >> but not yet allocated, how can I know that a pointer has not been
> >> allocated memory?
> >
> >
> > By writing your C code more carefully, and paying attention to warnings
> > from your compiler and lint. Assign NULL to all pointers that don't
> > currently point to any actual object, and let the tools help you with
> > obeying that rule.
>
>
> 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.
None of this means what you think it does.
You are correct in that the C++ standard requires the macro NULL to be
defined as an integer constant expression with a value of 0, the
simplest of which if just plain "0".
You are also correct in that the C standard allows the macro NULL to
have the same definition as C++ requires, or it allows it to be
defined as the same type of expression cast to pointer to void, that
is "(void *)0".
But neither of these possible definitions for the macro in either
language have any connection AT ALL to ADDRESS 0.
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.
IN A POINTER CONTEXT in C and C++, the literal "0" or macro "NULL" in
source code represents a null pointer, whatever the bit representation
of a null pointer actually is. And this is only true of literals in
the source code.
If ptr is a null pointer to any type, these are always true in C and
C++:
ptr == NULL;
ptr == 0;
But this is not required to be true:
int i = 0;
void *ptr = 0;
i == (int)ptr;
Most hardware architectures actually have something mapped at address
0, and most implementations use 0x00000000 as the binary
representation of a null pointer. But even if a processor and
compiler use something else for a null pointer, say 0xdeadbeef, at the
source code level this is still true:
void *ptr = 0; /* is a null pointer, even if the bits are not 0 */
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by Robert Adsett●February 17, 20072007-02-17
In article <tZKBh.6291$MN.3266@newssvr23.news.prodigy.net>, Vladimir
Vassilevsky says...
>
>
> Hans-Bernhard Br�ker wrote:
>
> >> So, if NULL (0x0000 0000) is not created when a pointer is declared
> >> but not yet allocated, how can I know that a pointer has not been
> >> allocated memory?
> >
> >
> > By writing your C code more carefully, and paying attention to warnings
> > from your compiler and lint. Assign NULL to all pointers that don't
> > currently point to any actual object, and let the tools help you with
> > obeying that rule.
>
>
> 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.
Not really. The C standard practically requires NULL be 0. The actual
phrase (if the reference I googled is correct) "an integral constant
expression with the value 0, or such an expression cast to type void *"
There may be wiggle room to allow the bit representation to be non-zero
but it would be simpler just to avoid the address 0.
Robert
--
Posted via a free Usenet account from http://www.teranews.com
Reply by Tim Wescott●February 17, 20072007-02-17
Jaime Andres Aranguren Cardona wrote:
> Hi,
>
> Working with VisualDSP++ 4.5 for BF, the documentation says:
>
> free
-- snip dead typical description of the free() function --
>
> Heaps may not start at address zero (0x0000 0000). This address is reserved
> and means �no memory could be allocated�. It is the null pointer on the
> Blackfin platform.
>
> So, if NULL (0x0000 0000) is not created when a pointer is declared but not
> yet allocated, how can I know that a pointer has not been allocated memory?
>
What are you trying to do? And wouldn't it make more sense to be
looking at the behavior of malloc?
The pointer itself is allocated when it is declared. In C you are
responsible for making sure that the pointer points to something. I
assume that in your case you want to violate good embedded programming
rules and assign memory off the heap*. It's your funeral, so you call:
myType * p = malloc(sizeof(myType));
The pointer will now either have a value of NULL (indicating that the
allocation failed) or a non-null value, indicating that the allocation
was a success. So test your pointer, and do the appropriate thing in
either case.
* there are situations where it's acceptable, but if you don't even
understand the behavior of malloc and free then you have some learning
to do before you'll understand the contexts in which using them in an
embedded system is safe.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Never cast the return value from malloc. Doing so hides errors
that you want to hear about, such as failure to include stdlib.h.
The best way to use it is:
TYPE *ptr;
...
if (!(ptr = malloc(N * sizeof *ptr))) {
/* take corrective action, malloc failed */
}
else {
/* all is well, you can use ptr */
}
which doesn't need alteration if you change the type of ptr. After
executing the line ptr will be NULL if the malloc failed (for
memory exhaustion, for example). Otherwise you are free to use
it. Remember that the allocated memory is uninitialized.
If your compiler complains about this either it is faulty or you
are using it as a C++ compiler. In general, a cast is probably an
error. Any time you use a cast you should clearly understant why
you need it and what it is doing. The major exception is arguments
to variadic functions, such as printf.
This is all standard stuff, specified by the ISO standard for C.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Reply by Vladimir Vassilevsky●February 17, 20072007-02-17
Hans-Bernhard Br=F6ker wrote:
>> So, if NULL (0x0000 0000) is not created when a pointer is declared=20
>> but not yet allocated, how can I know that a pointer has not been=20
>> allocated memory?
>=20
>=20
> By writing your C code more carefully, and paying attention to warnings=
=20
> from your compiler and lint. Assign NULL to all pointers that don't=20
> currently point to any actual object, and let the tools help you with=20
> obeying that rule.
The peculiarity of BlackFin is that 0x00000000 can be a perfectly valid=20
address. For that reason it would make sense to redefine NULL as=20
0xFFFFFFFF, for example. That can be done in C; however the C++=20
convention requres NULL =3D=3D 0.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Reply by Brad Griffis●February 17, 20072007-02-17
Jaime Andres Aranguren Cardona wrote:
> Hi,
>
> Working with VisualDSP++ 4.5 for BF, the documentation says:
>
> free
>
> --------------------------------------------------------------------------------
>
> deallocate memory
>
> Synopsis
> #include <stdlib.h>
>
> void free(void *ptr);
>
> Description
> The free function deallocates a pointer previously allocated to a range of
> memory (by calloc or malloc) to the free memory heap. If the pointer was not
> previously allocated by calloc, malloc or realloc, the behavior is
> undefined.
>
> The free function returns the allocated memory to the heap from which it was
> allocated.
>
> Error Conditions
> The free function does not return an error condition.
>
> Example
> #include <stdlib.h>
>
> char *ptr;
>
>
> ptr = (char *)malloc(10); /* Allocate 10 bytes from heap */
>
> free(ptr); /* Return space to free heap */
>
> See Also
> calloc, malloc, realloc
>
> Also, there exists this information:
>
> Tips for Working With Heaps
>
> --------------------------------------------------------------------------------
>
> Heaps may not start at address zero (0x0000 0000). This address is reserved
> and means �no memory could be allocated�. It is the null pointer on the
> Blackfin platform.
>
> So, if NULL (0x0000 0000) is not created when a pointer is declared but not
> yet allocated, how can I know that a pointer has not been allocated memory?
>
> Regards,
>
> JaaC
>
The malloc function will return a pointer to the start of the memory
being allocated to you from the heap. If your heap starts at address
zero then you could be given a pointer to address zero. The problem is,
that you as the programmer don't know if you've just been given a
pointer to address zero or if you've been given back a NULL pointer.
Avoid this situation by not declaring a heap at address zero.
Reply by ●February 17, 20072007-02-17
Jaime Andres Aranguren Cardona wrote:
> Hi,
>
> Working with VisualDSP++ 4.5 for BF, the documentation says:
[... none of this is particularly specific to the platform...]
> So, if NULL (0x0000 0000) is not created when a pointer is declared but not
> yet allocated, how can I know that a pointer has not been allocated memory?
By writing your C code more carefully, and paying attention to warnings
from your compiler and lint. Assign NULL to all pointers that don't
currently point to any actual object, and let the tools help you with
obeying that rule.