On Monday 10 May 2010 05:55:48 pm Milan Crha wrote: > From the code reading I understood that struct mapi_SPropValue and > struct SPropValue are not 1:1, some values which can be stored in struct > SPropValue are not possible to store in struct mapi_SPropValue, and/or > vice versa. I found these three as the beginning. It's preventing crash > for developer compiles. I'll come back to this part in a later email. I'll investigate a bit more.
> One more thing I forgot to mention in my previous email: I noticed that > cast_mapi_SPropValue allocates memory on the global memory context, but > only partially, the array itself, but not array items, which might mean, > if I read and understand the core properly, that values in mapi_sprop > are valid only until the sprop value isn't freed. It is good and bad in > the same time. I found that a copy_mapi_SPropValue() was useful in my initial work on server- side rules. It (also) isn't complete though... > It's good as you do not allocate some memory twice (only > the array, with actually no gain), but it's bad as it's undocumented and > if I would like to use new mapi_sprop after free of source sprop, then > I've a bad luck. I think that: > a) the cast function should have one more argument, the mem_ctx which > should be used for values and arrays which require memory allocation > b) items with string and byte values should be also allocated in the > given context Seems reasonable, unless we use the thing we're casting from. > c) I'm afraid of memory usage. Are these arrays allocated on the global > memory context freed with the mapi_sprop struct or on the program > exit/global memory context free? The later is something I would like to > avoid. But I do not know how exactly this works. All the MV_ stuff in in the global context. Possibly we could allocate it in the same context as the thing we're casting from. Then it would go away when you free the associated thing you're casting from. Julien? _______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
