pid_t.

* Fix a crashbug and a logic bug in hwcrhk_load_pubkey()

* Fix a crashbug and a logic bug in hwcrhk_load_pubkey()

1. some platforms do not have inttypes.h, and chasing them down
   becomes ridiculous.  Therefore, uint64_t can't be used for 64-bit
   values.
2. some (other) platforms do not support "long long".

Solution: make AEP_U64 a struct with two longs unless long already is
64 bit long.

Also, restore all other types back to use unsigned char, unsigned int
and unsigned long.  Make sure that AEP_U32 actually becomes 32 bits,
even on platforms where long is 64 bits (actually, we're just guessing
that int will stay at 32 bits on those...).

branches.

built-in types __int8, __int16 and so on on that platform.

Extentions of the explanations to the linking problem on Win32.  Provided by Andrew Gray <agray@iconsinc.com>

32-bit platforms.  Instead, make use of inttypes.h and use the types
defined there to get 8-, 16-, 32- an 64-bit values.

There might be some operating systems where one should use int_types.h
instead of inttypes.h.  Unfortunately, I don't recall which one(s).

be included for 0.9.6c-engine.

compile properly).

make update
perl util/mkerr.pl -recurse -write -rebuild

(now, just look at the effect that last thing had on the ENGINE error
strings!  How did that unbalance between macros and strings happen?)

Also, the "to" variable used in cleanup is never non-NULL and is entirely
unused. As such, the cleanup might have been missed under genuine error
conditions and caused leaks and/or returned invalid pointers.

to be pointless.