Table key smaller than 64bit

Question

Here is my some code. To reduce the data size, 'id', 'knight', and 'sale_id' are not uint64_t, even though they are keys. Because 'primary_key()', 'by_knight()' and 'by_saleid()' functions convert key to uint64_t.

It works, but I wonder if it can be used like this.

//@abi table item i64
struct item {
    uint16_t id = 0;
    uint16_t code = 0;
    uint8_t knight = 0;
    uint8_t level = 0;
    uint8_t exp = 0;
    uint32_t dna = 0;
    uint32_t saleid = 0;

    uint64_t primary_key() const {
        return id;
    }

    uint64_t by_knight() const {
        return knight;
    }

    uint64_t by_saleid() const {
        return saleid;
    }

    EOSLIB_SERIALIZE(
            item,
            (id)
            (code)
            (knight)
            (level)
            (exp)
            (dna)
            (saleid)
    )
};

typedef eosio::multi_index< N(item), item,
    indexed_by< N(knight), const_mem_fun<item, uint64_t, &item::by_knight> >,
    indexed_by< N(saleid), const_mem_fun<item, uint64_t, &item::by_saleid> >
> item_table;

Answer 1

Yes, this should be possible due to implicit conversion.

It is safe to do this going from low precision to high precision, i.e. from 8-bit to 64-bit.

However, doing it in the other direction may cause data truncation if the 64-bit integer is larger than the maximum size of the 8-bit integer, leading to unexpected results.

For example, if you have 724 stored in a 64-bit integer, it is represented in binary as:

000......1011010100

If this is implicitly converted to 8-bit, the number represented in binary will be:

11010100

Which is no longer 724, but 212. This can lead to very confusing bugs, so be careful with implicit conversions!