Building for earlier OS X versions : Check for NULL *address* of constants

  • In Apple's SDK Compatibility Guide > Using SDK-Based Development, it says…

    "Check the availability of an external (extern) constant or a notification name by explicitly comparing its address — and not the symbol’s bare name — to NULL or nil."

    It also says, regarding C *functions* that "the linker sets the address of unavailable functions to NULL".  Do they mean during the linking phase of building, or when the program loads (runtime)?

    More importantly, is the following code correct?  It looks weird.

    NSString* identifier ;
    if (&NSWorkspaceApplicationKey != NULL) {
        // We are running in Mac OS X 10.6 or later
        identifier = <expression using the bare name: NSWorkspaceApplicationKey> ;
    }
    else {
        // We are running in Mac OS X 10.5
        identifier = <some other expression> ;
    }

    Thanks,

    Jerry Krinock
  • Le 29 avr. 2013 à 03:59, Jerry Krinock <jerry...> a écrit :

    > In Apple's SDK Compatibility Guide > Using SDK-Based Development, it says…
    >
    > "Check the availability of an external (extern) constant or a notification name by explicitly comparing its address — and not the symbol’s bare name — to NULL or nil."
    >
    > It also says, regarding C *functions* that "the linker sets the address of unavailable functions to NULL".  Do they mean during the linking phase of building, or when the program loads (runtime)?

    They mean the dynamic linker. It happens at load time, not at compile time.

    > More importantly, is the following code correct?  It looks weird.

    While it may look weird, this is the way to do it.

    >
    > NSString* identifier ;
    > if (&NSWorkspaceApplicationKey != NULL) {
    > // We are running in Mac OS X 10.6 or later
    > identifier = <expression using the bare name: NSWorkspaceApplicationKey> ;
    > }
    > else {
    > // We are running in Mac OS X 10.5
    > identifier = <some other expression> ;
    > }

    -- Jean-Daniel
  • On 2013 Apr 29, at 00:15, Jean-Daniel Dupas <devlists...> wrote:

    > They mean the dynamic linker. It happens at load time, not at compile time.

    Thank you, Jean-Daniel.  I agree.

    So I just submitted a "Not helpful" on that document asking that they correct it.
  • Hi,

    When i compile my source directly from the terminal, I get the warning:

    deprecated conversion from string constant to 'char*'

    However if I let Xcode do the compiling, no warnings occur...

    How do I make Xcode show these warnings also, what checkbox to mark in
    the project settings?

    --
    Met vriendelijke groeten,
    Perry Winkel

    ZenoPX
    http://www.zenopx.nl

    Ir. P.F.M. Winkel
    +31(0)620-973979
    +31(0)26-8800407
  • On Thu, 2 May 2013 17:50:05 +0200, Perry Winkel said:

    > When i compile my source directly from the terminal, I get the warning:
    >
    > deprecated conversion from string constant to 'char*'
    >
    > However if I let Xcode do the compiling, no warnings occur...
    >
    > How do I make Xcode show these warnings also, what checkbox to mark in
    > the project settings?

    Xcode doesn't have checkboxes for every warning, you sometimes have to add extra warning flags in the 'other c flags' setting.  If you're using clang, I'm a fan of specifying "-Weverything" (which is literrally everything, and too much), and then disabling warnings you don't want by appending, for example, -Wno-foobar.

    Cheers,

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • On May 2, 2013, at 9:39 AM, Sean McBride <sean...> wrote:

    > Xcode doesn't have checkboxes for every warning, you sometimes have to add extra warning flags in the 'other c flags' setting.  If you're using clang, I'm a fan of specifying "-Weverything" (which is literrally everything, and too much), and then disabling warnings you don't want by appending, for example, -Wno-foobar.

    I'm a bit less aggressive, I just add "-Wall", which is less pedantic than "everything" mode but seems to include pretty much all the warnings I need.

    I've always wondered why there isn't a checkbox for this in the build settings...

    —Jens
  • Recently iOS Dev Weekly linked to a pretty decent article about warnings:

    http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/?
    utm_source=iOS+Dev+Weekly&utm_campaign=25515b4b70-iOS_Dev_Weekly_Issue_
    91&utm_medium=email


    I arrived at using -Wall -Wextra -Wno-unused-parameter (and may throw in -Wno-sign-compare for legacy projects).

    Gerd

    On May 2, 2013, at 11:55 AM, Jens Alfke <jens...> wrote:

    >
    > On May 2, 2013, at 9:39 AM, Sean McBride <sean...> wrote:
    >
    >> Xcode doesn't have checkboxes for every warning, you sometimes have to add extra warning flags in the 'other c flags' setting.  If you're using clang, I'm a fan of specifying "-Weverything" (which is literrally everything, and too much), and then disabling warnings you don't want by appending, for example, -Wno-foobar.
    >
    > I'm a bit less aggressive, I just add "-Wall", which is less pedantic than "everything" mode but seems to include pretty much all the warnings I need.
    >
    > I've always wondered why there isn't a checkbox for this in the build settings...
    >
    > —Jens
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Xcode-users mailing list      (<Xcode-users...>)
    > Help/Unsubscribe/Update your Subscription:
    > https://lists.apple.com/mailman/options/xcode-users/<gerti-xcode...>
    m

    >
    > This email sent to <gerti-xcode...>
  • On Thu, May 2, 2013 at 1:23 PM, Gerd Knops <gerti-xcode...> wrote:
    > Recently iOS Dev Weekly linked to a pretty decent article about warnings:
    >
    > http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/?
    utm_source=iOS+Dev+Weekly&utm_campaign%515b4b70-iOS_Dev_Weekly_Issue_91
    &utm_medium=email

    >
    > I arrived at using -Wall -Wextra -Wno-unused-parameter (and may throw in
    > -Wno-sign-compare for legacy projects).
    -Wsign-conversion is important to catch C/C++/Obj C promotions, where
    -1 > 1 after promotion. This happens because a signed int is promoted
    to an unsigned int when mixing the data types. You might consider it
    for all projects.

    -Wstrict-overflow? That warns of optimizations taken due to illegal
    code. That is, if something leads to undefined behavior (*not*
    implementation defined), the compiler just removes it. For example,
    signed integer overflow is undefined and removed (Intel's ICC is
    especially aggressive). Unsigned integer wrap is implementation
    defined and left in place. See, for example
    http://www.airs.com/blog/archives/120.

    -Wcast-align? Both x86/x64 and ARM processors fixup misaligned data at
    a cost (sometimes its expensive). Earlier ARM processors (ARM4 and
    possibly AR5 (I don't recall the cutoff)) simply SIGBUS on you. See,
    for example, http://www.gnu.org/software/gsl/manual/html_node/GCC-warning-options-for-nu
    merical-programs.html

    (it shows up in an odd place).

    -Weverything is noisy, but I would *not* patently recommend not using
    it as  Begemann in the article. If you use it, you need to learn to
    separate the wheat from the chaff with -Wno-XXX.

    There's lots more *really* good warnings out there. There are lots of
    other goodies available for this stage in the development process. The
    trick is you have to ask for them.
    https://www.owasp.org/index.php/C-Based_Toolchain_Hardening.

    Jeff

    > On May 2, 2013, at 11:55 AM, Jens Alfke <jens...> wrote:
    >
    >
    > On May 2, 2013, at 9:39 AM, Sean McBride <sean...> wrote:
    >
    > Xcode doesn't have checkboxes for every warning, you sometimes have to add
    > extra warning flags in the 'other c flags' setting.  If you're using clang,
    > I'm a fan of specifying "-Weverything" (which is literrally everything, and
    > too much), and then disabling warnings you don't want by appending, for
    > example, -Wno-foobar.
    >
    >
    > I'm a bit less aggressive, I just add "-Wall", which is less pedantic than
    > "everything" mode but seems to include pretty much all the warnings I need.
    >
    > I've always wondered why there isn't a checkbox for this in the build
    > settings...
previous month april 2013 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
29 30          
Go to today