• 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: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?


  • Subject: Re: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?
  • From: Kyle Sluder <email@hidden>
  • Date: Fri, 07 Mar 2014 08:50:33 -0800

On Mar 7, 2014, at 4:54 AM, Bill Cheeseman <email@hidden> wrote:
>
> My code calls -[NSArray objectAtIndex:]. I compile it with Xcode 5.0.2 on OS X 10.9.x Mavericks in a project with the target's Base SDK set to 10.9 and the OS X Deployment Target set to OS X 10.7. It works fine when I run it on OS X 10.9 or OS X 10.8.
>
> However, when I run it on Mac OS X 10.7 Lion, I get a runtime error claiming it encountered an invalid argument, namely, the unrecognized selector -objectAtIndexedSubscript:. The NSArray Class Reference notes that -objectAtIndexedSubscript: is available only in OS X 10.8 and later, and that it is "identical to objectAtIndex:". Of course, -objectAtIndex: still exists in the 10.9 API, and it is not marked as deprecated.
>
> It appears, therefore, that the compiler generated a call to -objectAtIndexedSubscript: even though my source specifies -objectAtIndex: and a deployment version of 10.7.
>
> Has anyone else encountered this? -- I don't find anything in my searches. It seems like a serious bug that would have cropped up for practically everybody.

-objectAtIndexedSubscript: is what the compiler generates when it sees square-bracket indexing syntax applied to an NSArray:

  NSArray *a = …;
  foo(a[0]); // generates call to -objectAtIndexedSubscript:

It’s unfortunate that the compiler doesn’t catch that you’re targeting 10.7, where this method does not exist, and prevent such syntax.

>
> My actual code is this:
>
>     NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSSystemDomainMask, YES) objectAtIndex:0];

This doesn’t look like the code that’s breaking. Is that really what’s on the stack when you crash? If so, that’s a pretty serious compiler bug.

>
> I could try casting the result of NSSearchPathForDirectoriesInDomains() to type NSArray* or break this statement into two parts with an intermediate NSArray local variable, but I can't see why that would make any difference.
>
> Is there any way to work around this?
>
> I notice that the 10.7 Lion SDK is not part of the Xcode 5 installation. Do I have to add the 10.7 Lion SDK? -- and how would I go about doing that?

The Lion SDK is not supported with Xcode 5.

--Kyle Sluder

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?
      • From: Greg Parker <email@hidden>
References: 
 >NSArray's objectAtIndex compiles to objectAtIndexedSubscript? (From: Bill Cheeseman <email@hidden>)

  • Prev by Date: Re: No longer existing outlet causes crash in new version of app (iOS)
  • Next by Date: Re: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?
  • Previous by thread: Re: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?
  • Next by thread: Re: NSArray's objectAtIndex compiles to objectAtIndexedSubscript?
  • Index(es):
    • Date
    • Thread