Re: After 2.2.1: 'AliasRecord' has no member named 'aliasSize'. UNTRUE!!
Re: After 2.2.1: 'AliasRecord' has no member named 'aliasSize'. UNTRUE!!
- Subject: Re: After 2.2.1: 'AliasRecord' has no member named 'aliasSize'. UNTRUE!!
- From: Eric Albert <email@hidden>
- Date: Thu, 19 Jan 2006 09:18:16 -0800
On Jan 19, 2006, at 5:56 AM, Jerry Krinock wrote:
Thank you, Eric.
on 06/01/18 19:30, Eric Albert at email@hidden wrote:
When in doubt, take a look at the header.
Better: When in state of complete confusion, take a look at the header.
Actually, I should've pointed you to the Universal Binary Programming
Guidelines too:
<http://developer.apple.com/documentation/MacOSX/Conceptual/
universal_binary/index.html#//apple_ref/doc/uid/TP40002217>
See the "Guidelines for Specific Scenarios" chapter, and specifically
the "Aliases" section.
In this case, you'll see in
Aliases.h that the AliasRecord struct is opaque if
MAC_OS_X_MIN_VERSION_REQUIRED >= MAC_OS_X_VERSION_10_4. In other
words, if the "Mac OS X Deployment Target" setting for your project is
10.4 or later, the AliasRecord struct is opaque.
Yes, Deployment Target was the difference between Project A and
Project B.
I now get consistent behavior with both of them, depending on
Deployment
Target:
Deployment Target Result
----------------- ----------------------
COMPLIER_DEFAULT same AliasRecord error
10.2 no errors
10.3 no errors
10.4 same AliasRecord error
However, the above results were obtained after I pasted in your
suggested
code:
Here's how to write your code in a way that'll work no matter what
your
deployment target:
AliasRecord aliasHeader = *(AliasPtr)[decodedData bytes];
#if MAC_OS_X_MIN_VERSION_REQUIRED >= MAC_OS_X_VERSION_10_4
nBytesAliasRecord = GetAliasSize(&aliasHeader) ;
#else
nBytesAliasRecord = aliasHeader.aliasSize ;
#endif
Personally, I am fine with changing from COMPILER_DEFAULT in Project B
to
10.2 for this particular project, but I'd like to understand what is
going
on. I'm sure I did not change Project B's Deployment Target since
yesterday. COMPILER_DEFAULT worked fine in Xcode 2.2 but gave this
error
after 2.2.1. Project B did cause a lot of internal errors in Xcode
for the
first few hours or so. They seem to have stopped now, after several
re-launches.
Rather than changing to 10.2, you should use per-architecture
deployment targets. You don't really want to use a deployment target
earlier than 10.4 for Intel, since there are no pre-10.4 Intel systems.
Xcode supports setting MACOSX_DEPLOYMENT_TARGET_ppc and
MACOSX_DEPLOYMENT_TARGET_i386, so if you want either of those to be
different from the compiler default, set it to the value you want.
That's because AliasRecords, as you've noticed, get written to disk
but
are also referenced in data, which means that they often have to be
big-endian even on little-endian systems. Rather than enumerate the
cases in which you'd want big- or little-endian AliasRecords, we made
the data type opaque and added new APIs which deal in native-endian
data. They're Get/SetAliasUserType and GetAliasSize, and there are
also FromPtr versions of each if you have an AliasRecord * instead of
an AliasHandle.
Sounds like I'd better test this section of code very carefully on the
Intel
Mac.
For what it's worth, in the code I've encountered which accesses the
fields of an AliasRecord, switching to the new functions has always
worked fine. It's unlikely that you'll have code which assumes those
fields are big-endian or anything like that. That's not to say you
shouldn't test it -- it's good to test anything you change, of course
-- but rather that I think it has a pretty good shot of working the
first 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:
This email sent to email@hidden