Add support for allocating heap instead of stack memory

[MU-Software]

The main purpose of this PR is to use this library in a special case with more heap space than stack.
ex) ESP32 can have external memory (PSRAM), but that can be used only for heap allocation. Previously, using this library on a ESP32 without any modification causes a stack corruption.
(sizeof(struct datastream) might take 8901bytes(1+2+2+8896), and ESP32's default task stack size is 4 KB.) We can solve the problem by moving some stack variables to heap.

This can be enabled by defining QUIRC_USE_HEAP macro, define this before import, or add -D QUIRC_USE_HEAP flag while compiling.

[dlbeer]

On Sun, Jan 09, 2022 at 09:35:38AM -0800, MUsoftware wrote:

The main purpose of this PR is to use this library in a special case with more heap space than stack.
ex) ESP32 can have external memory (PSRAM), but that can be used only for heap allocation. Previously, using this library on a ESP32 without any modification causes a stack corruption.
(sizeof(struct datastream) might take 8911bytes, and ESP32's default task stack size is 4 KB.) We can solve the problem by moving some stack variables to heap.

This can be enabled by defining QUIRC_USE_HEAP macro, define this before import, or add -D QUIRC_USE_HEAP flag while compiling. You can view, comment on, or merge this pull request online at:

I've just had a chance to look over the patch now. I understand the problem, however:

• Are you sure that the polynomials in the Berlekamp Massey algorithm need to be heap-allocated? The datastream makes sense, as it's nearly 9kB, but these polynomials are only a couple of hundred bytes all up.

• There's no point using calloc() if you're just allocating one item and it's getting memset called on it anyway.

• There are no checks for memory allocation failure here.

• It would probably be better to introduce an small wrapper macro and

  ifdef its implementation, rather than having #ifdefs at every call

  site. Having the ifdefs scattered through the function mean that changes are more likely to introduce bugs for different configurations.

My suggestion would be to either:

• Introduce a wrapper macro for dealing with large on-stack objects.

• Or, identify the few buffers that are large and allocate them once at object initialization. This would probably be best, as you then wouldn't be hitting the memory allocator on each frame.

One other very quick-and-dirty alternative is to just mark the problematic buffers as static. That's a bit ugly, but I'm guessing you have only one instance of the object on your memory-constrained system?

-- Daniel Beer @.***> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B