On Wed, Jun 29, 2005 at 04:44:09PM -0400, Scott Erickson wrote:
> (In PalmTypes.h)
> #define _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR(table, vector, selector) \
> __attribute__ ((__callseq__ ( \
> "move.w #" _PalmTypes_OS_CALL_Str(selector) ",-(%%sp); " \
> "trap #" _PalmTypes_OS_CALL_Str(table) "; dc.w "
> _PalmTypes_OS_CALL_Str(vector))))
>
> (In HsExt.h - redef location)
> #define _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR(table, vector, selector) \
> __attribute__ ((__callseq__ ( \
> "move.w #" _Str(selector) ",-(%%sp); " \
> "trap #" _Str(table) "; dc.w " _Str(vector))))
>
> I dont know much about what this define is used for, so I dont know if it is
> safe to remove the one in Hs. What is the best way to deal with this
> problem, or is it not going to be a problem at all???
The correct solution [1] is to wrap a #ifndef around these #defines, in both
PalmTypes.h and HsExt.h:
#ifndef _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR
#define _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR([...]) [...]
#endif
Probably you always #include <PalmOS.h> or so in your source files
before any palmOne headers, so you could get away with only wrapping the
one in HsExt.h. And in fact it's only a warning and isn't causing any
other damage, which might constitute "not going to be a problem" for you.
Alternatively, you could update to the 5.0 palmOne SDK released last
week, which uses a dumb hack to avoid this warning (instead of avoiding
it by using the infrastructure that's been added to PalmTypes.h for
their benefit, sigh).
It's interesting to look at how this situation has arisen.
The ultimate expansions of both #defines are the same, so it doesn't
matter which one you end up using. In the past, the definitions in both
places were identical, so the redefinition was benign and didn't require
a diagnostic (C99 section 6.10.3). The definitions became non-identical
and the diagnostic required with the Fall 2004 Palm OS SDK, when someone
renamed PalmTypes.h's _Str macro to _PalmTypes_OS_CALL_Str. This change
could be cordially described as being an instance of "a little knowledge
is a dangerous thing".
_OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR used to be defined and used only
in the palmOne (ne Handspring) headers. With the Fall 2004 update,
Handspring's 5-way navigation functions have graduated to the platform
SDK, and they and their _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR (which is
a mere implementation detail for most of us) are in the process of
moving to the Palm OS SDK. During the transition, they appear in both
sets of headers. Ideally HsExt.h would use the platform's definition
of _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR (from PalmTypes.h) if available
and fall back to its own definition otherwise. Eventually, when the
updated Palm OS SDK was ubiquitous, palmOne would remove the now
unneeded definition from HsExt.h.
Instead, they've renamed things in HsExt.h so that it's further divorced
from the infrastructure in PalmTypes.h. This is unfortunate; that
infrastructure was designed precisely so that this complex and limiting
code wouldn't need to be duplicated into headers like HsExt.h.
John
[1] This is the correct solution for someone in Scott's position,
hacking SDKs to get rid of spurious warnings. From PalmSource's
point of view, I suspect the correct solution is for HsExt.h to
#include <PalmTypes.h> *and* wrap its own definition of the macro.
This reflects the longer term goal of PalmTypes.h providing this
infrastructure cleanly. Wrapping the PalmTypes.h one would reflect
the transitional state of moving the macro from HS headers to the
platform ones, and it would be unfortunate if PalmTypes.h contained
the detritus of this transition long after the transition was over.
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
