Am 09.10.2014 um 01:09 schrieb Eric Blake:
On 08/29/2014 03:41 PM, Max Reitz wrote:+ * cluster_count clusters; therefore, we have to allocate + * cluster_count - contiguous_free_clusters new clusters at the end of + * the image (which is the current value of cluster; note that cluster + * may exceed old_nb_clusters if *first_free_cluster pointed beyond the + * image end) */ + *nb_clusters = cluster + cluster_count - contiguous_free_clusters; + *refcount_table = g_try_realloc(*refcount_table, + *nb_clusters * sizeof(uint16_t)); + if (!*refcount_table) { + return -ENOMEM; + } + + memset(*refcount_table + old_nb_clusters, 0, + (*nb_clusters - old_nb_clusters) * sizeof(uint16_t));Is this calculation unnecessarily hard-coded to refcount_order==4?
While now in the process of editing this patch, no, this is not hard-coded to that refcount_order. It's hard-coded to *refcount_table being uint16_t *. I think this fine. Making the in-memory refcount table support variable refcount orders would be pretty hard and in fact we do not need it before we actually support other refcount_orders. When doing that, I (or anyone else) will probably add some function read_refcount() which reads a refcount from a refcount block or a concatenation of refblocks (such as this in-memory refcount table) while taking into account a variable refcount_order. When that is done, we can rework this code.
But for now it's fine to make the in-memory refcount table entries uint16_t, which is the reason for all the sizeof(uint16_t).
Max
