Messages in this thread | | | Subject | Re: [patch 3/4 -mm] flex_array: poison free elements | From | Dave Hansen <> | Date | Mon, 24 Aug 2009 14:42:36 -0700 |
| |
On Mon, 2009-08-24 at 13:41 -0700, David Rientjes wrote: > On the other hand, I'd have no problem trying to eliminate > fa->total_nr_elements (since we already have fa->element_size) since we > can calculate it in real-time; the only problem is being able to > distinguish when the elements are being stored in struct flex_array vs. > being stored in struct flex_array_part.
Yeah, that's the only reason it's there: to determine if we're using the compact form or not. We could probably find another place to store that, or just store a flag telling whether we're using that form or not. We couldn't do the bounds-checking, but I'm OK with that.
But, honestly, it doesn't *really* bother me if we just use two 32-bit int slots in the 'struct flex_array'. The 64-bit code has an extra 4 bytes now anyway.
> We could then use that > unsigned int in struct flex_array to store the number of inuse elements > which is an alternative implementation to flex_array_shrink(), yet I'd > still propose to keep the poisoning to reveal use-uninitialized.
I kinda like the idea of truncating more, just because its simpler and doesn't have any assumptions about the contents. But, you are right that poisoning has some distinct benefits, namely allowing sparsely used arrays to shrink.
-- Dave
| |