On Feb 6, 2006, at 5:29 PM, John Mikros wrote:
> We are in the process of porting an existing CodeWarrior CFM
> project to Mach-O and then to Xcode.
>
> Our codebase had a function called Sleep which, unsurprisingly,
> would cause the current thread to sleep for a given number of
> milliseconds. This compiled, linked and ran properly with
> CodeWarrior Mach-O. However, when we build the same project under
> Xcode, we find that our Sleep function causes linker errors,
> because OSServices already contains a function named Sleep. This
> doesn't appear to be a documented call--it isn't even in the
> Framework headers--but it actually puts the entire computer to
> sleep! Definitely a surprise if you're not expecting it :)
>
> I can work around this problem by #defining Sleep to
> __BlizzardSleep__ in our headers, but I was under the impression
> that SPIs weren't this easy to access. Isn't there some mechanism
> in the OS (e.g. two-level namespaces) to prevent Apple from
> polluting our namespace, and vice-versa?
>
Nope, two level namespaces are only for loading plugins, not for the
system frameworks. Your code and the frameworks it links with all
swim in the same smallish pool of identifiers, and there's no special
segregation of Apple unpublished SPI from published API.
Sleep() is one of the ugly legacy ones that was created in the mists
of time and has a tendency to conflict with user code. Most modern
calls (SPI and API) have prefixes that identify which subsystem they
belong to and help to segregate Apple from user entry points. But
years of Carbon code relies on Sleep() so it has to be carried forward.
Redefining your Sleep entry point is the right thing. Using
__BlizzardSleep__ is not necessarily correct, as the quoting double
underscore convention is used for header guard macros. Just #define
Sleep BlizzardSleep should be sufficient.
Chris
