Quote from: jgarzik on November 27, 2012, 09:26:57 PM

Yes, embedded usage is another target.

Each module in libccoin is carefully designed to minimize internal dependencies. The core data structures, address generation, script execution and transaction validation are wholly independent of any filesystem or network design.

These modules may be used on a non-POSIX flash filesystem, with zero network support, today.

picocoin (the client) requires certain network, filesystem and process features, but libccoin (the library) does not. This is by design.

But even the definitions in your "ccoin" include files are deeply incompatible with any standalone environment, even if it uses GCC toolchain. Major rework would be required even now, when there's just couple of hundred lines of code.

The big-endian compatibility is already super-confusing. Istead of using uint32_t in bu256_t use an "union le_int32" to at least flag the mixing of little endian uint32_t with guint32_t.

From my extensive commercial experience of porting from Linux/Posix/Intel-only code to anything standalone or lightweight OS will unfortunatly go through the "first deny then rewrite from almost scratch" stages.

If I may suggest two things:

1) from the start build also on Mac Leopard or Snow Leopard to verify the endian-neutrality with "-arch ppc" with Rosetta on Intel CPU. Edit: Never mind, I forgot that you have access to the Linux on POWER and z/Arch through your association with RedHat.
2) obtain any embedded development/simulation environment. If you have any Xilinx Spartan6 boards (with memory) laying around you could use them to test using MicroBlaze CPU with Xilinx EDK/SDK.

Thank you for yor time.