Can anyone help me to find a small, simple XML-parser that can read and write from/to file AND does not use realloc() or alloca()?

In order that we can maintain the quality of this support service I would respectfully request that this forum is only used to post questions that are directly related to FreeRTOS. Thanks.

Of course. The absence of realloc() and alloca() is because FreeRTOS has currently no support for them. That’s the link to FreeRTOS.

Use heap_3.c, it just wraps the standard library functions. You can wrap the calloc function in the same way.

That would work. But degrades overall performance of all other tasks. I heavily use malloc() and free().

If you use malloc and free in a multi-thread/task system, then malloc/free MUST be made aware of this as the wrapper does, otherwise you run the real risk of corrupting your heap. Some implementations will define hooks inside of these functions that you can define that might make the cost a bit smaller, but it still needs to be there.

You are right.  I forgot to mention that I use heap4.c for dynamice memory (de-)allocations.

iIs you code calling pvPortMalloc or malloc? If the latter, you are at risk of corrupting the heap unless you are guarding all calls yourself. To get a calloc/realloc for the first case, either switch to heap3.c and add the simple to define functions, or write the corresponding functions for the heap4 implementation. calloc should be fairly simple, as it just needs a little math, call malloc, and then clear the buffer. realloc will take a bit more work, but there are plenty of examples of how to write a realloc around.

I use the heap4 functions, not the standard malloc and free (by including the “-Dmalloc pvPortMalloc “-Dfree pvPortFree” on the commandline). My app is running nicely, so no problems there. Calloc() is no issue. realloc() is doable, but what about alloca()? alloca() allocates the (variable length) memory on the stack instead of the FreeRTOS-heap.

alloca() is a somewhat non-standard function (I don’t think it is defined in the ISO standards), but by its general nature, is should be thread safe as it allocates from the stack and each thread has its own stack. The one danger is that you would need to know if the version of alloca (assuming it is provided by your implementation) is compatible with the way FreeRTOS moves the stack. If your implementation does NOT provide an alloca(), then it may be possible to write one yourself, but it will need to be written in assembly, as it can not be written in C, and needs a fairly good understanding on how your compiler works, snd there will likely be strange restrictions on you code to make sure your program still works (declaring new variables after the alloca likely will not work right unless the compiler knows about alloca.) Most programs that use alloca can be changed to use malloc, the biggest issue is finding where to put the free call, which is the best choice if alloca isn’t supported for you.

The GCC based compiler I use for PIC32 (XC32) has a alloca.h header which contains  the following:

#define alloca(x)   __builtin_alloca(x)

For temporary (variable size/number) allocations, alloca() would be very useful. It can help to eliminate fragmentation of the heap because these allocations are task-local. Long life allocations would still use the heap. Any suggestions on how to determine whether the default alloca() is 100% compatible to FreeRTOS?

The one thing I can think of is look at the generated assembly, and make sure that the code it generates doesn’t include a check for the stack pointer compared to a global variable, if it does, then it likely won’t work with FreeRTOS, if not it should. The problem is that alloca is often very simple, and if you ask for too much memory it just over runs the stack. This sort of operation should be compatible with FreeRTOS, as it doesn’t us any knowledge of the programs memory layout that is changed by FreeRTOS. “Nicer” versions might detect the stack overflow, but these will get confused by FreeRTOS as the stack for a task isn’t in the space the stack started out to be. The good news is that most alloca()s are the quick and dirty versions that don’t error check. It would make sense, at least for debugging, to make sure that you have turned on the FreeRTOS stack checks if you use alloca(), as it does make it much harder to estimate stack usage.

Thank you! I will look into this the next few days and report back.