On Friday 13 February 2009 11:33:18 pm Julien Kerihuel wrote: > On Fri, 2009-02-13 at 22:34 +1100, Brad Hards wrote: > > libmapi/mapidump.c:59: warning: cast from pointer to integer of different > > size libmapi/freebusy.c:291: warning: cast from pointer to integer of > > different size libmapi/freebusy.c:292: warning: cast from pointer to > > integer of different size > > See r1149, they *should* be fixed. Since I have no x64 machine, it's > just a blind commit ... The buildbot says OK :-)
<snip warnings in utils/openchangeclient.c> > Will fix those in a further commit if the above works for you. Now I have the pattern, I can do this if you like. > I don't think that moving from a single common-purpose function to a > wide variety of atomic and _PUBLIC_ functions would be worthwhile here. > > This would impact the caller function which is assumed to be the > developer's application (since functions are marked as _PUBLIC_) and > probably make his code more complicated. I was planning to keep the existing functions, so presumably old code would keep working, but you are right - it would be more complex. > If we have a set of public functions for almost every MAPI type we can > fetch, this means the calling application is responsible for doing MAPI > property tag lookup and the dispatch/fetch switch case on its own > (similarly to find_mapi_SPropValue_data internals). Well, presumably we know what the "right" data type is (because we'll have to cast the void* to that type). > I'd rather like to keep our single method, but maybe introduce a > function which looks whether the property's data is mapped to a (const > uint32_t *) error or not. so find_SPropValue_data_noerror(struct SRow *aRow, uint32_t mapitag) or similar that just returns NULL if the property type is an error? > Apart from the above considerations, I prefer prototypes similar to: > _PUBLIC_ enum MAPISTATUS find_SPropValue_data_MV_LONG(struct SRow *aRow, > uint32_t mapitags, const struct LongArray_r *MVl) > > returning MAPI_E_SUCCESS on success, otherwise MAPI error and setting > MVl contents to NULL. I thought about that too. That would be useful so we can tell between "it was there, but was an error", and "it wasn't there". That might be worth thinking about as part of a general API review at some point. I'd like to do it "sometime later" but I'm also conscious that we really don't want to be changing public API ... Anyway, the problem is basically sorted for now. Brad _______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
