Fix pointer arithmetic (invalid use of void)

[dexterbg]

gcc in pedantic mode fails to compile umm_malloc.c because of the void * arithmetics:

umm_malloc.c:326:49: error: invalid use of 'void'
     c = (((void *)ptr) - (void *)(&(UMM_HEAP[0]))) / UMM_BLOCKSIZE;

See e.g. https://stackoverflow.com/a/3524270 and https://stackoverflow.com/a/25375321

[rhempel]

Thanks for this - every MR gets reviewed (eventually). I just happened to have some time for this little hobby project this morning :-)

Can I ask you to let me know a bit more about where you are using umm_malloc? I can see from your GitHub profile that you have an interest in vehicle monitoring systems ...

[dexterbg]

Ralph,

on the contrary, thank you for the lib :-)

I'm one of the main developers on the OVMS project, an all open source vehicle monitoring solution:

• https://www.openvehicles.com/
• https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3

The OVMS includes Duktape (https://github.com/svaarala/duktape) to support Javascript plugins on the vehicle module. We're running the system on an ESP32 using a modified esp-idf release 3. We've had the issue of the standard memory management getting into trouble with the allocation/freeing pattern of the Javascript heap & garbage collection, leading to the overall system slowing down significantly over time.

Your library is now managing the Duktape heap on a dedicated chunk of main memory, which solves the issue. As a very welcome side effect, scripting performance has got a boost of factor 3-8, depending on how memory intense the script is.

I can't tell how much of that speed boost is because umm_malloc doesn't need to take care of locking or poisoning in this use case, and the allocations also don't need to be tracked for the FreeRTOS task monitoring. According to Angus from Espressif (https://www.esp32.com/viewtopic.php?t=8628#p36412), their allocator was also originally based on your work, but they went on to an own implementation to support multiple memory regions with different capabilities.

You wrote:

You can even use it on a bigger project where a single process might want to manage a large number of smaller objects, and using the system heap might get expensive.

So… consider that confirmed :-)

Regards,
Michael