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 22:28:04 +0200
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:
This email sent to email@hidden