For those of us not in the loop, COSE[1] is CBOR Object Signing and Encryption, with CBOR being a binary JSON alternative. It is patterned off JOSE, the JSON standards which includes favorites like JWK.
2 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. Pretty close to the start of the real code: https://github.com/wolfSSL/wolfCOSE/blob/b90b34abcba90aa7b8a... . Sure it's just 1 pointer but 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.
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.
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
Some stricter interpretations also require that maximum stack usage can be statically analyzed (ie. no recursion, no function pointers, no VLAs/alloca).
[1]: https://www.rfc-editor.org/info/rfc9052/
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. Pretty close to the start of the real code: https://github.com/wolfSSL/wolfCOSE/blob/b90b34abcba90aa7b8a... . Sure it's just 1 pointer but 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.
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.