Added unit tests, and fixed two bugs:

[vtnerd]

trafficstars

• Integer conversion checks in src/wire/read.h
• Missing "boolean" function in wire::writer and derived types

This is similar to #52 but should fix the integer checking issue, and adds unit tests for the wire code. Eventually the two fixes will be PR'ed onto the release branch, but the unit tests will likely not (at least not initially).

I doubt many people will want to go through this review, so I will leave it here for ~2 weeks and then just merge. Look out for lest.hpp which is from another project, but somewhat easy to review.

[vtnerd]

Force pushed a timestamp correction on the commit, and nothing else.

[jeffro256]

The bug fixes look good, but I don't know anything about lest. Is there an upstream repo you could add as a submodule?

[vtnerd]

There is a github repo, but I'm not sure what a submodule provides in this scenario given that just a single file is needed.

[vtnerd]

@jeffro256 @j-berman @serhack I just force pushed a new change to this PR - I simplified the integer handling a bit further. The previous version was adapted from a blog post, which has unclear copyright issues. I didn't need anything that complicated for conversion, as you can see from the code changes and tests.

[vtnerd]

BTW compare the changes here.

[vtnerd]

Also - I might make the type templated again after a bit of thought. This will help with performance optimizations, etc.

[vtnerd]

Moved back to templated source for the casting functions.

[jeffro256]

I don't know if you should move towards splitting the conversion function into different types of functions. The whole reason I found the bug is that the new JSON code in the wire module in the monero project used an integer conversion going from int64_t to uint64_t (IIRC). At some point you may need a cast_unsigned_to_signed and cast_signed_to_unsigned? I liked the convert_to function as it was... maybe I could reach out to the blogger and ask for copyright clarification?

[vtnerd]

The functionality isn't needed right now, did you have some (specific) future use case in mind? Are you implementing a variant/fork where this function was useful? There's still boost::numeric_cast, which has a heavier code generation (for the error case). I think you can mess with the policies a bit to help with that.

The JSON code only needs int64_t -> uintmax_t and uint64_t -> intmax_t, which is simpler than any source and target type (that was provided by the previous function). The tricky case is if uintmax_t::max < intmax_t::max, which seems to be rare (and presumably is handled by the aforementioned boost function).

[jeffro256]

Sorry for the delay of this comment o_0. Are you planning to use this integer conversion code for the monero serialization module?

[vtnerd]

Yes.

[jeffro256]

K then I guess I'll just check how that code uses these integer conversion functions when I get there.