Adding message length to the callbacks

[elichai]

This will help a lot for downstream code that doesn't have easy access to libc(strlen etc.)

Any thoughts about this?

cc downstream rust-bitcoin/rust-secp256k1#115

(I wasn't sure when is CHECK vs VERIFY_CHECK is used so would appreciate a feedback if I used it right)

[real-or-random]

Ah, I considered this too in rust-bitcoin/rust-secp256k1#115. :)

The problem with this approach is that

1. It adds a dependency to strlen(). I think with all our recent efforts for supporting embedded systems, this part of the PR is rather a step back.
2. It breaks the callback API, see Allow to use external default callbacks #595 on discussions about whether it is okay to break this or not.

The first point is easily solved by implementing strlen on our own, it's just three lines.
The second point is difficult.

My take is rather that downstream should implement strlen if it requires it. It's also just three lines there.

edit: Another thing we could do here is to guarantee a fixed minimum message size. This will be somewhat arbitrary but could be useful. Then the user knows "it's okay to print exactly X bytes" (and maybe I don't print the full message then but I'm not doing anything wrong).

[elichai]

hmm shouldn't embedded systems has some sort of a libc?
Altough I can see why people would want to compile to embedded without linking to anything.

if we need to implement that anyway then I guess downstream could implement this as easily as us.

I'll leave this PR open for a while see what other people think about this.

Regarding breaking the API I do agree with #595 (comment) that if the change is good then it's mostly fine (these callbacks should almost never be called and most people won't provide their own callbacks)

[real-or-random]

Unless someone else will have a different opinion until tomorrow i'll close this PR.

Yeah or maybe wait somewhat longer, my single opinion is not authoritative of course (nor is anyone else's.)