Surprising Inline Behavior Change
File this in the unexpected result department.
I just answered a customer issue involving some 68K code that worked with CW for Palm OS 8.3, but failed with 9.2. It was code that loaded a shared library in situation where global variables weren't available. It used a standard call to SysLibFind, passing a string constant for the name of the library. This code started failing with the V9 tools.
The culprit ended up being inline functions. This code was part of an inline function, and a compiler change in the Metrowerks C/C++ frontend caused this developer some grief.
Let's examine a simple inline function:
inline const char *foo(void) foo
With PC-relative strings turned on, this code would return a PC-relative string in V8, but it would return a pointer into global space with V9. The issue is how the compiler interprets inline functions. This is an inline function with external linkage. This means that every copy of foo in every file needs to return a pointer to the same string "foo". In V8, this was broken -- if you compared the pointers from a call to foo from one file to one from another file, you'd get a mismatch. We fixed this in V9 by forcing the string "foo" into a global variable shared among all instances of foo.
There's a simple fix. Change the code to read
static inline const char *foo(void) foo
This will declare foo as having internal linkage. The need for all of the "foo" strings to be the same string will go away, and the compiler will again put "foo" into the code space where it can be accessed safely when global variables aren't available.
Send feedback to combee@techwood.org
Copyright © 2004 Benjamin L. Combee
Palm OS is a registered trademark of PalmSource, Inc.
Metrowerks and CodeWarrior are registered trademarks of Metrowerks Inc.
The views expressed on this website/weblog are those of mine alone and do not necessarily reflect the views of PalmSource or Metrowerks.
qwertYAK / frobnovich
|
