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

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

I'm not sure what your question has to with free()! If you declare a pointer but don't initialise it, it's value is indeterminate; i.e.:

int *p;

p could point anywhere. Therefore, it is safest to initialise pointers on declaration, typically to NULL, i.e.:

int *p = NULL;

Then you will always know that the pointer should not be used until a value has been assigned with malloc(), etc.

--
Oli

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

=20

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

... snip ...

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.

--
 
 
 
 "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

-- snip dead typical description of the free() function --

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

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

On Sat, 17 Feb 2007 16:04:16 -0600, Vladimir Vassilevsky wrote in comp.arch.embedded:

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

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

Apparently

Robert

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

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