alt Hacker News2 things of notice in the readme as recently I've been in the efficient binary communication hunt:
1. .text size without clarifying the architecture, flags, and compiler is meaningless unless it's all rodata (and it's not)
2. Saying it takes 0 .bss and .data just means it allocates everything elsewhere and that can be helpful to know. Of course in compilation that'll also be dependent on how and for what it's built. To say it's zero alloc is incorrect or at best misleading. Here's a line of code that allocates a ton of stuff on the stack: https://github.com/wolfSSL/wolfCOSE/blob/b90b34abcba90aa7b8a... (previously pointed to another line but it was diluting my thesis). Anyone in embedded who's had to increase stack size to use a fancy function knows what I'm talking about. I'm looking at you, sscanf. Some of this code will allocate hundreds if not low thousands of bytes onto the stack. Which is maybe fine but don't say it's zero alloc just because it's all on the stack.
Replies
That line allocates nothing. The function is their version of explicit_bzero(). The line casts an existing pointer passed in (e.g. pointing to something on the stack, or allocated by you) to a volatile pointer, which prevents the compiler from optimising away the writes.
Their README states "zero dynamic allocation: all operations use caller-provided buffers" and "Full COSE lifecycle in ~<1KB RAM (excluding wolfCrypt internals)", so I assume their stack usage is low too, because you (the caller) will own and have to allocate all buffers yourself
My understanding of zero alloc is that there are no heap allocations i.e. use of a form of malloc. At least that has always been my experience, use of the stack is perfectly fine
I used to think that zero alloc = zero malloc, and all stack allocations are of statically known fixed size (you know the max call depth), so you can preallocate your stack area with some confidence, and will never run out of RAM.
The line you point at creates a single local pointer variable which is used in a tight loop; I don't see why won't it stay entirely in a register.
I'm not a real embedded developer though; last time I worked as one I worked on 8-bit devices. Maybe things changed since then.