On Thu, Oct 8, 2009 at 7:46 PM, Vitaliy wrote: > Tamas Rudnai wrote: > >> Of course you have to be careful when using dynamic memory allocation, > >> but > >> you can't just assume that if you use it you will have memory leaks, > >> memory > >> unbalancing problems, and "big and hardly recoverable problem". You > don't > >> need malloc() to write buggy code. > > > > I agree with that. All I am saying is when the memory allocation mapping > > collapses youor entire system crashes, while if only a piece of memory is > > corrupted the system might survive. > > I don't understand; why do you say that "entire system crashes"? It's not > that difficult to handle "OUT OF MEMORY" cases, you can make the system > fail > gracefully. > I was talking about memory leak problems and buffer overrun problems where the memory mapping information can be corrupted (depending on how the memory manager keeps track of the used/unused memory regions). For example if the memory region is a linked list, then an inappropriate pointer can destroy one the link that could cause virtually loosing the control over the heap -- a reset can only satisfactory solve the problem. > > I think what Isaac meant is that if your application doesn't have enough > >> memory to do what it needs to do, you should get a chip with more RAM! > > > > It depends. If it saves more money on the development phase than the > > smaller > > device would do on the production, then I agree with you on this. > > The point is that you can run into the same problem ("out of memory") with > static memory allocation. It's not a problem inherent to dynamic memory > allocation. > However, with static allocation you will be informed by the compiler or the linker that there is a problem -- and not when the customer is asking for help. Tamas > > Whether malloc() et al are available on the target system, is another > matter. > > Vitaliy > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.mcuhobby.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist