Get rid of dynamic memory allocations in libnrsc5?

[argilo]

libnrsc5 allocates memory using malloc in various places. For instance, the convolutional decoder allocates a relatively large trellis object at the start of each decode, and frees it when finished. Each memory allocation opens up the possibility of an allocation failure, and in many cases libnrsc5 fails to check the return value of malloc.

Since most things in the NRSC-5 standard are of fixed or bounded size, I expect that hardware receivers use a static memory layout. It may be worth taking this approach in libnrsc5 as well.

[TheDaChicken]

Would you also want to remove the dynamic memory allocations for the API too?

[argilo]

By "libnrsc5", I meant everything inside the API boundary. Did you have something else in mind?

[TheDaChicken]

Just double-checking. I currently cannot think of any other better way.

When using callbacks on the API, I have to copy memory into my own variables since I cannot take ownership of the memory. That is completely OK. This may make more sense if the memory was stack allocated, copying would be the only correct option.

[argilo]

That's right. API clients must copy any data they wish to retain after returning from the callback, and that wouldn't change if we got rid of dynamic memory allocations in libnsc5.

The API could in theory be changed such that the client is responsible for freeing memory allocated by libnrsc5, but I think that would be more of a burden on the API client, and likely to lead to memory leaks.