>
> On 19.03.2010, at 10:31, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
> > Hmm, we get this build time warning on 32-bit systems now:
> >=20
> > Fl_Preferences.cxx: In member function `void*
> > Fl_Plugin_Manager::addPlugin(const char*, Fl_Plugin*)':
> > Fl_Preferences.cxx:1927: warning: cast from pointer to integer of
> > different size
> >=20
> > That's from Manolo's %p substitute code, I guess a 64-bit system would
> > through the equivalent warning at line 1929 instead...
> >=20
> > Looks like it will do the Right Thing at runtime of course, but do we
> > care about this warning? Can we do the equivalent check with ifdef's =
> at
> > compile time as an alternative?
>
> Yes, I am not very happy with the current code. Is there a C++ approved =
> cross platform 64-bit safe method to convert a pointer into an ASCII =
> string and back?
Matt:
I see you've come up with a nice coding of these damn pointer values.
Meanwhile, I had come up with this union-based solution that compiles
without warning and runs correctly on all 3 platforms:
// HAVE_P_SCANF would mean that scanf("%p", &pointer) runs correctly
#ifndef HAVE_P_SCANF
union pointer_unsigned {
#ifdef HAVE_LONG_LONG
long long unsigned llu;
#endif
long unsigned lu;
unsigned u;
void *pointer;
};
static void *pointer_scanf(const char *buf)
{
union pointer_unsigned pu_union;
#ifdef HAVE_LONG_LONG
if (sizeof(void *) == sizeof(long long))
sscanf(buf, "%llx", &pu_union.llu);
else
#endif
if (sizeof(void *) == sizeof(long))
sscanf(buf, "%lx", &pu_union.lu);
else
sscanf(buf, "%x", &pu_union.u);
return pu_union.pointer;
}
#endif // HAVE_P_SCANF
/**
* \brief Return the address of a plugin by index.
*/
Fl_Plugin *Fl_Plugin_Manager::plugin(int index)
{
char buf[32];
Fl_Plugin *ret = 0;
Fl_Preferences pin(this, index);
pin.get("address", buf, "@0", 32);
#ifdef HAVE_P_SCANF
sscanf(buf, "@%p", &ret);
#else
ret = (Fl_Plugin*)pointer_scanf(buf + 1);
#endif
#ifdef FL_PLUGIN_VERBOSE
printf("Fl_Plugin: returning plugin at index %d: (%s) %p\n", index, buf, ret);
#endif
return ret;
}
Please, see what solution you prefer.
Manolo
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
