On Fri, 2009-02-13 at 22:34 +1100, Brad Hards wrote: > I'm looking for how to fix the warnings that occur on 64-bit machines > associated with comparing property values with error values. > > 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 ...
> utils/openchangeclient.c:2683: warning: cast from pointer to integer of
> different size
> utils/openchangeclient.c:2684: warning: cast from pointer to integer of
> different size
> utils/openchangeclient.c:2693: warning: cast from pointer to integer of
> different size
> utils/openchangeclient.c:2694: warning: cast from pointer to integer of
> different size
> utils/openchangeclient.c:2703: warning: cast from pointer to integer of
> different size
> utils/openchangeclient.c:2704: warning: cast from pointer to integer of
> different size
Will fix those in a further commit if the above works for you.
> There would appear to be two options - never return an error value
> (always make it NULL so we can just check for that), or add functions
> that return the right type (or NULL) rather than a single function
> that returns a void*. Here is a conceptual view:
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.
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).
Keeping existing routines and add this new function set also means we
will be providing 2 different methods to fetch MAPI data. This would -
IMHO - be more confusing than convenient ; the easier is the interface,
the quicker developers find how to use it.
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.
> +_PUBLIC_ const struct LongArray_r *find_SPropValue_data_MV_LONG(struct SRow
> *aRow, uint32_t mapitag)
> +{
> + uint32_t i;
> +
> + for (i = 0; i < aRow->cValues; i++) {
> + if (aRow->lpProps[i].ulPropTag == mapitag) {
> + struct SPropValue *lpProps = &(aRow->lpProps[i]);
> + if (lpProps->ulPropTag == 0) {
> + return NULL;
> + }
> +
> + if ( (lpProps->ulPropTag & 0xFFFF) == PT_MV_LONG) {
> + return &(lpProps->value.MVl);
> + }
> + }
> + }
> + return NULL;
> +}
> +
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.
Cheers,
Julien.
--
Julien Kerihuel
[email protected]
OpenChange Project Manager
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
