• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sleep and Xcode
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

References: 
 >Sleep and Xcode (From: John Mikros <email@hidden>)

  • Prev by Date: Re: crash in __static_initialization_and_destruction on 10.3.9 but not 10.4.4?
  • Next by Date: Re: Upgrade Error: Xcode 2.2 & GCC 4.0.1
  • Previous by thread: Sleep and Xcode
  • Next by thread: Upgrade Error: Xcode 2.2 & GCC 4.0.1
  • Index(es):
    • Date
    • Thread