Re: Sleep and Xcode
Re: Sleep and Xcode
- Subject: Re: Sleep and Xcode
- From: Chris Espinosa <email@hidden>
- Date: Mon, 6 Feb 2006 21:50:22 -0800
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 |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden