On Mar 9, 2014, at 8:31 AM, Ken Thomases wrote:
> On Mar 9, 2014, at 7:21 AM, Bill Cheeseman wrote:
>
> The above three lines use the new-style array subscripting syntax (e.g.
> versionComponentStrings[0]). That's the source of the crash, since that
> support is not available in your deployme
On Mar 9, 2014, at 8:31 AM, Ken Thomases wrote:
> On Mar 9, 2014, at 7:21 AM, Bill Cheeseman wrote:
>
>> NSArray *versionComponentStrings = [versionString
>> componentsSeparatedByString:@"."];
>> static unsigned long sBCDSystemVersion = 0;
>> SInt32 majorVersion = ([versionComponentSt
I just realized that there is a bug in my +QSWStandardizedSystemVersion method
that explains the crash. The fault is NOT the -objectAtIndex: message. It is
instead the 3
versionComponentStrings[x] subscripted messages, which of course compile to
-objectAtIndexedSubscript:. I was thinking of
On Mar 9, 2014, at 7:21 AM, Bill Cheeseman wrote:
>NSArray *versionComponentStrings = [versionString
> componentsSeparatedByString:@"."];
> static unsigned long sBCDSystemVersion = 0;
>SInt32 majorVersion = ([versionComponentStrings count] >= 1) ?
> [versionComponentStrings[0] intV
ml.
NSString *errorDesc = nil;
NSPropertyListFormat format;
NSString *rootPath =
[NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSSystemDomainMask,
YES) objectAtIndex:0]; // <-- -objectAtIndex: call
NSString *plistPath = [rootPath
stringByAppendingPathComponent:@"C
AtIndexedSubscript:. 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 dep
On Mar 9, 2014, at 4:09 AM, Bill Cheeseman wrote:
> On Mar 7, 2014, at 2:42 PM, Greg Parker wrote:
>> The arclite glue library is supposed to add that method at runtime if it
>> does not exist.
>>
>> Perhaps arclite is not being linked in somehow? The machinery for linking
>> arclite is compl
On Mar 7, 2014, at 2:42 PM, Greg Parker wrote:
> The arclite glue library is supposed to add that method at runtime if it does
> not exist.
>
> Perhaps arclite is not being linked in somehow? The machinery for linking
> arclite is complicated and I forget what it is supposed to look like in
On Mar 7, 2014, at 12:40 PM, Aaron Tuller wrote:
> Is this by any chance a 32-bit app?
No, it is Standard Architectures (64-bit Intel)(x86_64).
The offending code is in a custom framework of mine installed in
/Library/Frameworks, also Standard Architectures. No ARC -- everything is old
fash
On Mar 7, 2014, at 8:50 AM, Kyle Sluder wrote:
> On Mar 7, 2014, at 4:54 AM, Bill Cheeseman 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
>>
On Mar 7, 2014, at 4:54 AM, Bill Cheeseman 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
On Mar 7, 2014, at 4:54 AM, Bill Cheeseman 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
On 7 Mar 2014, at 6:54 AM, Bill Cheeseman 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
otes 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
> -obj
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
Thank you, that answers my question,
Nava
On Nov 1, 2009, at 10:24 PM, Sherm Pendley wrote:
On Sun, Nov 1, 2009 at 2:44 PM, Nava Carmon wrote:
NSObject *anObject = [anArray objectAtIndex:i];
...
Should I release it?
No. You didn't create anObject with +alloc or a method beginning with
-
On Sun, Nov 1, 2009 at 2:44 PM, Nava Carmon wrote:
>
> NSObject *anObject = [anArray objectAtIndex:i];
...
> Should I release it?
No. You didn't create anObject with +alloc or a method beginning with
-copy, nor did you send it a -retain message. Therefore you do not own
it and must not release it
That line alone does not indicate any memory leaks occurring due to
over-retaining objects. You'll need to provide more context (the
surrounding code, etc).
The object returned by -[NSArray objectAtIndex:] is the actual object
(ie. pointer to the actual object's space in memory)
Hi,
When I ran Build and Analyze on my code, it has pointed as a possible
leak the following statement:
NSObject *anObject = [anArray objectAtIndex:i];
anObject wasn't released and here's the question: whether anObject is
a copy of actual object, that is a member of anArray or it's the
o
19 matches
Mail list logo
