Unclear object code when wrong types are used accessing inline numeric conversion routines in numeric.c

[danielkilbo]

Numerous calls to inline numeric converter routines using dangerous construction.
Non pointer parameters are treated as pointer (indexed) in inline code without any type conversion.
Unclear how different compilers interpret the type mismatch.

Example (look at how variable L is used):
`void dtls_mac(dtls_hmac_context_t *hmac_ctx,
const unsigned char *record,
const unsigned char *packet, size_t length,
unsigned char *buf) {
uint16 L;
dtls_int_to_uint16(L, length);

assert(hmac_ctx);
dtls_hmac_update(hmac_ctx, record +3, sizeof(uint16) + sizeof(uint48));
dtls_hmac_update(hmac_ctx, record, sizeof(uint8) + sizeof(uint16));
dtls_hmac_update(hmac_ctx, L, sizeof(uint16));
dtls_hmac_update(hmac_ctx, packet, length);

dtls_hmac_finalize(hmac_ctx, buf);
}
static inline int dtls_int_to_uint16(unsigned char *field, uint16_t value)
{
field[0] = (value >> 8) & 0xff;
field[1] = value & 0xff;
return 2;
}`

Correct types should be used on the parameters. Type casting the parameter lets the compiler at least check if the parameter is a reference or not.

[joakimeriksson]

OK, yes. this is a significantly bad naming in tinydtls. uint16/32/64 are in fact arrays and not the regular uint16_t vars. So uint16 x;= uint8_t x[2];

[joakimeriksson]

Fixed in the dtls-standalone branch - all strange typedefs removed.