rofl0r
why is it that cmake church members keep pushing their build system down other people's throats. are you getting paid for this?
> I have yet to meet someone that was OMG I [heart] autoconf. > (modern cmake!) > https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ let me complement this "modern cmake" article with the "modern autoconf" article...
i thought about this some more and i came to the conclusion that in order to keep future problems to a mininum it's probably not a good idea to make...
btw according to `man 0p stddef.h`, stddef.h is the proper header to include to get this type.
otoh, there are also applications like bruteforcing where you would want to avoid dynamic allocation, since even on fast malloc impls you have a cost of about 300 cpu cycles...
is that documented somewhere ? maybe a paragraph above the commented out option in tomcrypt-config.h should warn about the UB invoked by it.
also: in C the proper type for sizes is size_t, not unsigned long. (usually it's the same, but some odd platforms like windows have a 32bit long on 64bit).
i like the zeromem struct approach best. i wonder why there's not been any comment by @sjaeckel or @karel-m since this seems to be a serious issue.
> Does anyone think it's worth to keep the old approach alive? (probably as LTC_BURN_STACK) if the initial analysis posted by OP is correct, the old approach uses undefined behaviour....
using vla's is the worst possible choice. there have been countless numbers of CVE's due to it. also it doesn't make the code simpler at all, now every call site...