> > > >>>> + kfree(gts->avail_all_scales_table); > > > > ... > > > >>>> + per_time_gains = kcalloc(gts->num_itime, sizeof(int *), GFP_KERNEL); > >>> > >>> sizeof(type) is error prone in comparison to sizeof(*var). > >> > >> Yes and no. In majority of cases where we see sizeof(*var) - the *var is no > >> longer a pointer as having pointers to pointers is not _that_ common. When > >> we see sizeof(type *) - we instantly know it is a size of a pointer and not > >> a size of some other type. > >> > >> So yes, while having sizeof(*var) makes us tolerant to errors caused by > >> variable type changes - it makes us prone to human reader errors. Also, if > >> someone changes type of *var from pointer to some other type - then he/she > >> is likely to in any case need to revise the array alloactions too. > >> > >> While I in general agree with you that the sizeof(variable) is better than > >> sizeof(type) - I see that in cases like this the sizeof(type *) is clearer. > > > > Still get a fundamental disagreement on this. I would insist, but I'm not > > a maintainer, so you are lucky :-) if Jonathan will not force you to follow > > my way. > > In a code you are maintaining it is good to have it in your way as > you're responsible for it. This is also why I insist on having things in > a way I can read best for a code I plan to maintain - unless the > subsystem maintainers see it hard to maintain for them. So, let's see if > Jonathan has strong opinions on this one :) This is one where I strongly prefer sizeof(*per_time_gains) because it's easier to review. I don't care so much if it's easier to modify as reality is these rarely get modified. I often just 'fix' these up whilst applying. Jonathan
