> > > Or he may want to write his own free(). > > > > He is not allowed to do this (the C standards explicitly > > forbids that an application overrides a library implementation), > > and this would not work in almost /any/ C environment, because > > the way free() must be implemented is completely tied to the > > implementation of malloc() itself. > > > This sure explains the rationale. Thanks for the details.
On the other hand, this should not stop you from implementing your own memory manager if you believe you understand your application's needs and usage patterns, and you believe that a better mechanism for the application would improve it's memory usage. For example, FreeRTOS comes with 3 different "heap managers" (or malloc/free pairs) with different ideas about how dynamic memory should be managed. In each case, the heap manager is pre-allocated a chunk of RAM that it manages. In our application, we've taken one of the heap managers and tweaked it further as we've seen how memory is actually used. Rather than calling the routines "malloc" and "free", the routines are called "pvPortMalloc()" and "vPortFree()". From a strict maintenance point of view, I prefer to have a specially named function for my heap manager instead of renaming malloc() and free(). This will tell a later programmer that he is not looking at the "box standard" malloc but at a custom heap manager. In the embedded world, the programmer can and must control many things that are handed to him in the "big compute" world of PCs. Memory management is one of those things. Realize that, while the C compiler and library are the enablers, *you* must decide how to manage the resources available to you. That is the blessing and curse of programming microcontrollers. Best regards, Stu Bell DataPlay (DPHI, Inc.) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
