karel-m

I do not think that the build system is currently our biggest trouble. Anyway, my opinion for the future: * keeping makefile.unix + makefile.mingw + libtomcrypt_VS2008.* * dropping makefile.msvc *...

FYI: branch `pr/autotools` contains an autotools attempt (disclaimer: it does not mean that I am interested in implementing and/or maintaining the autotools stuff; quite the opposite is true)

I have added one more wycheproof failing test labeled "Edge case for Shamir multiplication" - in this case we reject a signature that is valid (which is less dangerous).

Added to more cases (both ASN.1 length encoding) when we accept signature that wycheproof guys consider invalid.

Yes, the trick with `-DARGTYPE=4` is exactly what I did. But for example Fedora/RedHat guys for some reason insist on linking with system's libtomcrypt. The thing is that the `ARGTYPE==0`...

The only issue I see with `char*` case is the fact that some people may assume that `char*` means passing/returning a string with `NUL` byte at the end, which is...

You are right `base64_encode` and `base64url_encode` do append NUL byte; however, `base32_encode` does not (it should at least for consistency). Decoders are IMO not a problem.

> yeah, it should! you can add it to #353 if you want to :) I think #353 seems like ready to merge, I'd fix it in a separate PR....

@sjaeckel do you see any troubles with switching to use 'char*' in base64_* ?

FYI: there are two related PR #366 and #367 I would like to propose changing: ```C int base16_decode(const char *in, unsigned char *out, unsigned long *outlen) ``` to: ```C int...