John, thanks for the clear and complete explanation! --
Scott Erickson Software Development Team, FB-4, Inc. [EMAIL PROTECTED] "John Marshall" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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/
