On 14/10/2010 14:23, Malte Timmermann wrote: > Hi, > > OK, I was not aware that we also want to fix a bug with size limitation, > didn't look at the referenced issue :o. > > Of course this is great then! :) > > But in needs to be discussed whether size_t is a good data type here. > > While size_t is good for generic containers, it is at least unusual for > other classes in our multi platform toolkit. > > SfxItemPool shouldn't have different max sizes on different platforms, > so it should have something with a fix size like sal_uInt32.
i have now come to the same conclusion. > For the stream operators, I think it's mandatory to use a fix size: You > can't make best assumptions on for what the stream operators are being used. > > If there is an API where I can store/load with a SvStream, I expect it > can also be used for multi platform persistency. So size_t is not > appropriate here for storing the count. yes, indeed. my latest advice to Bartosz includes limiting the Put method to not accept more than 2^32 elements, and changing the relevant SfxItemPool method parameter and return types to sal_uInt32. > Malte. -- "Invention, it must be humbly admitted, does not consist in creating out of void but out of chaos. Any artist knows these truths, no matter how deeply he or she submerges that knowing." -- Jonathan Lethem (quoting Mary Shelley) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
