EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

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

Started by Jaime Andres Aranguren Cardona February 17, 2007
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 &#4294967295;no memory could be allocated&#4294967295;. 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



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

On Sat, 17 Feb 2007 20:32:04 -0000, Jaime Andres Aranguren Cardona  
<jaac@nospam.sanjaac.com> 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 &ldquo;no memory could be allocated&rdquo;. 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?
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
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.
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 &#4294967295;no memory could be allocated&#4294967295;. 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.

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
Jaime Andres Aranguren Cardona wrote:
>
... snip ...
> > #include <stdlib.h> > > char *ptr; > > ptr = (char *)malloc(10); /* Allocate 10 bytes from heap */ > > free(ptr); /* Return space to free heap */
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
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 &#4294967295;no memory could be allocated&#4294967295;. 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
In article <tZKBh.6291$MN.3266@newssvr23.news.prodigy.net>, Vladimir 
Vassilevsky says...
> > > Hans-Bernhard Br&#4294967295;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
On Sat, 17 Feb 2007 16:04:16 -0600, Vladimir Vassilevsky
<antispam_bogus@hotmail.com> wrote in comp.arch.embedded:

> > > Hans-Bernhard Br&#4294967295;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

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

The 2024 Embedded Online Conference