Implement the multihash format as described at multiformats/multihash.

Implement the unsigned variable integer format as described at multiformats/unsigned-varint.

As of Version 0.7.0, the function az_uvarint_decode allocates a buffer of length bytearray.len, with each type being the width of uint8_t; however, this buffer is assigned to a variable of type az_bytearray_t, not uint8_t. As the widths of uint8_t and az_bytearray_t differ greatly, this is quite a serious memory corruption issue.

The offending line is as follows:

Implement the multistream format as described at multiformats/multistream.

Implement the multiaddr format as described at multiformats/multiaddr.

Static code checking needs to be added to the build process and Continuous Integration (CI) build chain.
I have struggled to add OCLint to our Travis CI configuration (over 20 failed builds in fact) to no avail. OCLint seems to do the actual job of static checking well enough; however, it is extremely intolerant to different build systems and CI (despite what their documentation might suggest).

Automated memory checking is currently not performed anywhere along the CI build chain. To ensure memory safety, this will need to change.

The best tool for this is likely Valgrind; however, ASAN is also an option.

To assist with QA/QC, code coverage for the unit test suite is desperately needed. Furthermore, this must be able to be added to the existing automated CI chain via Travis.

Feel free to recommend code coverage solutions for C code in this thread.

Implement the multibase format as described at multiformats/multibase.

There is a dummy type declared in src/azorian.h to satisfy ISO C11 compliance taking issue with empty translation units. This dummy type should be called __dummy_type_for_iso_compliance; however, (at least currently) it is called __dummy_type_for_ios_compliance:

Implement the multicodec format as described at multiformats/multicodec.

Often, as a quick validation check, the length of a az_bytearray_t will be checked to ensure it's at least three bytes long, due to inference from the actual multiformat specifications themselves. While this is technically valid, the current codebase is now littered with nasty magic numbers.

These belong in a macro constant of some sort, perhaps defined in src/azorian.h.