A caution for those moving to gcc 4.0.1
A caution for those moving to gcc 4.0.1
- Subject: A caution for those moving to gcc 4.0.1
- From: Daniel Jalkut <email@hidden>
- Date: Thu, 19 Jan 2006 19:56:14 -0500
In my efforts to port my applications to Universal builds for the
recent Intel machines, I discovered a funny behavior related to gcc
4.0.1. I thought others might run into a similar problem, or worse
yet, may not realize they are exposed to the problem until their
users report bugs based on their old data.
The bug is this: @encode(UInt32) and @encode(SInt32) return different
values when compiled with gcc 4.0.1 than they do when compiled with
gcc 3.3. This was discussed in an earlier thread, but the problem
wasn't pinpointed precisely to UInt32 and SInt32. (There may be
others, but they don't affect my projects).
What does this mean? It means that if your encoded/archived objects
use UInt32 or SInt32 values, and your users have archived objects
(e.g. preferences or documents) that were saved with your gcc 3.3
built application, those archived objects will fail to unarchive when
your gcc4.0.1 built application tries to open them. Pretty nasty!
A workaround that I've decided on is to hardcode the "old value" for
@encode(UInt32) in my sources, so I can ensure that the archiver
expects (and continues to store) the data encoding tag that I used to
get from gcc3. For example, a line of source code:
[encoder encodeValueOfObjCType:@encode(UInt32) at:&_modifiers];
Now reads:
[encoder encodeValueOfObjCType:"I" /* @encode(UInt32) */
at:&_modifiers];
Without this change, the value of @encode(UInt32) would be "I" when
built with gcc 3.3 and "L" when built with gcc 4.0.1.
I figure hard-coding this value is safe because the result of @encode
() is a compile time value and "I" is still valid for referring to a
32-bit unsigned value.
Even if you don't explicitly encode UInt32 or SInt32, let me suggest
that you test your application's ability to read archived data
carefully after updating to gcc 4.0.1. For instance, many system
data types are defined in terms of these fundamental types, and the
derived types exhibit the same problem. For instance, in one of my
projects I encode the CoreAudio type "MusicDeviceInstrumentID" which
is in turn a UInt32. I've had to hardcode this to "I" to retain
compatibility with older archives, as well.
Hope this helps somebody!
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden