I imagine that dealing with completely whacked out FSRefs is a *lot*
like workign with completely invalid MenuRefs (say a deallocated
CFStringRef) and calling IsValidMenu() in that what it contains may
not be important. The difference being that an FSRef has to be an
FSRef (even if it contains random data) whereas an Invalid MenuRef is
fruit and cake. Say FSRefs contain a volume reference number. If this
is random data, then the vrefnum just won't point to a valid volume.
If it also contains a file ID, then having a file ID with random data
would just mean a different file or a non-existent file.
I think everyone's over thinking the situation and trying to think up
random cases in which this will break when none of these cases may
exist. Especially if FSRefs are just numbers and not pointer
addresses.
Ack, at 10/19/05, Laurence Harris said:
Why not? The API is FSIsFSRefValid(), not FSRefObjectExists(). I have lots
of places in my code where it might call FSGetCatalogInfo on an FSRef that's
all zeroes and there's never been a problem. Are you aware of a problem? If
so I'd like to know about it. Of course, if you're specifically wanting to
know if an FSRef is all zeroes it's simple enough to write a test for that
and save a call to a OS API.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
