Re: Serious problem with XCode 2.2 treating unsigned long differently ?!
Re: Serious problem with XCode 2.2 treating unsigned long differently ?!
- Subject: Re: Serious problem with XCode 2.2 treating unsigned long differently ?!
- From: Eyal Redler <email@hidden>
- Date: Sun, 13 Nov 2005 23:47:56 +0200
I've done some tests and it seems that my theory is incorrect which
makes the puzzle even bigger.
I thought that the fact that the application compiled using XCode 2.1
could open previous archives while the one produced with XCode 2.2
could not read the archives produced by 2.1 meant that getting an 'I'
while expecting 'L' would produce an error while getting an 'L' while
expecting an 'I' would be OK but it seems as if this is not the case.
Using Xcode 2.2 the following code will give either:
*** Uncaught exception: <NSArchiverArchiveInconsistency> *** file
inconsistency: read 'I', expecting 'L'
or
*** Uncaught exception: <NSArchiverArchiveInconsistency> *** file
inconsistency: read 'L', expecting 'I'
Depending on how you combine the unsigned int/long in the
initWithCoder/encodeWithCoder.
I understand that what's producing the exception is Cocoa and not
XCode but there is no way this explains how the Xcode 2.1 built
version could read previous archives...
@interface ERTestEncoding : NSObject
{
TestTypeLong instanceVar;
}
@end
@implementation ERTestEncoding
- (id)initWithCoder:(NSCoder*)coder{
self= [super init];
if (self)
[coder decodeValueOfObjCType:@encode(unsigned int) at:&instanceVar];
return self;
}
- (void)encodeWithCoder:(NSCoder *)coder{
[coder encodeValueOfObjCType:@encode(unsigned int)
at:&instanceVar];
}
@end
int main (int argc, const char * argv[]){
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
ERTestEncoding* object=[[ERTestEncoding alloc] init];
[NSUnarchiver unarchiveObjectWithData:[NSArchiver
archivedDataWithRootObject:object]];
[object release];
[pool release];
}
On Nov 13, 2005, at 22:33, Eyal Redler wrote:
Correction I meant to say
When version C tries to read a version B archive it fails and emits
the "*** file inconsistency: read 'I', expecting 'L'" bit. but
version B had no problem reading version A.
On Nov 13, 2005, at 22:28, Eyal Redler wrote:
Thanks for the answer Eric,
This is becoming even more puzzling since I have built the
application in the past using Xcode 2.1 (I'm assuming gcc 4.0
since I never touched the settings) and there was no problem
opening archives that were created by previous versions of XCode.
First the specifics. I have this defined
typedef unsigned long ERType;
and then I have the instance variable
ERType myVar;
and then I encode it like this
[coder encodeValueOfObjCType:@encode( ERType) at:&myVar];
Now the puzzler, let's assume that I have three versions of the
application A, B and C.
A was compiled using Pre XCode2.1/gcc 3.3 and will encode ERType
as 'L'
B was compiled using XCode2.1/gcc 4.0 and will encode ERType as 'I'
C was compiled using XCode2.2/gcc 4.0.1 and will encode ERType as 'L'
When version C tries to read a version A archive it fails and
emits the "*** file inconsistency: read 'I', expecting 'L'" bit.
but version B had no problem reading version A.
It looks as though NSCoder has no trouble reading 'L' while
expecting 'I' but the other way around will fail. Is this correct?
Is this intentional or is it just a bug?
I'd suggest unarchiving those classes with gcc 4.0 and re-
archiving them with 4.0.1 or 3.3, if you can do that. If not,
you might have to re-create the archives.
This is not really possible, people have used the gcc 4.0 version
and I cannot re-create their documents and settings.
As a general comment, I think you have a problem here with the
release documentation. The minuet I saw this problem I started to
scan the documentation and was not able to find any mention of this.
Best regards,
Eyal
On Nov 13, 2005, at 21:04, Eric Albert wrote:
On Nov 13, 2005, at 10:22 AM, Eric Albert wrote:
On Nov 13, 2005, at 2:48 AM, Eyal Redler wrote:
This looks like a very serious issue and I'm wondering whether
anyone has seen this problem and knows how to work around it.
After upgrading to XCode 2.2 and building my application, the
application could no longer un-archive some classes and
produced the following message in the console:
*** file inconsistency: read 'I', expecting 'L'
Looking into it I found out that the @encode directive produces
a different result for "unsigned long" under XCode 2.2 then it
did under XCode 2.1.
Please file a bug report with details of what you're encoding.
The part of the compiler which handles this was rewritten in
Xcode 2.2 and was found to be fully compatible with the previous
version in very extensive testing, but perhaps we missed a case.
Actually, I think I'm slightly off on this one. The part of the
compiler which handles this was rewritten for Xcode 2.1/gcc 4.0,
and was done so in a way that wasn't compatible with gcc 3.3 and
earlier releases. This was fixed for Xcode 2.2/gcc 4.0.1 to be
backwards compatible with gcc 3.3. Unfortunately, you seem to
have some classes which were encoded with gcc 4.0. (If you were
building with gcc 3.3 in Xcode 2.1, this is a different bug.)
I'd suggest unarchiving those classes with gcc 4.0 and re-
archiving them with 4.0.1 or 3.3, if you can do that. If not,
you might have to re-create the archives.
Hoping I have it straight this time,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40netvision.net.il
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40netvision.net.il
This email sent to email@hidden
_______________________________________________
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