logoalt Hacker News

Neywinytoday at 12:48 AM4 repliesview on HN

But it puts sizeable arrays on the stack. That's not really better since instead of an out of memory exception it'll just corrupt the stack of on the majority of embedded implementations that don't have hardware stack protection in use or available.


Replies

adrian_btoday at 12:54 PM

I have looked into the header "wolfcose.h".

It contains a bunch of configurable parameters, including the 64-byte size of those buffers.

Based on those configurable parameters, which also impose limits on the depth of procedure calls, it is possible to compute which will be the maximum space that will be needed in a stack. Thus in an embedded system it would be possible to guarantee that the stack size is not exceeded.

By changing the values of those configuration parameters, it should be possible to tune the size of the stack, with the price that with a lower space available in the stack it may become impossible to decode certain more complex messages.

magicalhippotoday at 4:10 AM

So I think they're correctly saying this is non-allocating, since it doesn't internally malloc, but I also think you're right to criticize their stack spam.

I think it would be better if they made you pass a struct with those arrays and such as members, then you get to chose if you want to put it in global memory to ensure they're available or if you take your chance on a local stack instance.

Asmod4ntoday at 10:16 AM

VLAs can’t be used in portable code at all.

Or what do you mean with sizeable arrays?

show 1 reply