Sleep and Xcode

  • 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?
  • 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
previous month february 2006 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28          
Go to today