[Openmcl-devel] dfsl/foreign function oddities
Chris Curtis
enderx12 at mac.com
Fri May 13 20:03:39 PDT 2005
On May 13, 2005, at 8:11 PM, David Steuber wrote:
> On May 13, 2005, at 10:07 AM, Chris Curtis wrote:
>
>> I suspect that this might have something to do with the fact that
>> __CFStringMakeConstantString is not officially a published API,
>> since it's the only function that gets this error. I'm just not
>> knowledgeable enough about the guts of the #_ interface to even
>> know where to start.
>>
>
> Just an FYI for Chris and anyone else interested,
> __CFStringMakeConstantString is the macro expansion of the C macro
> CFSTR. There are a few places in the Carbon APIs where Apple has
> used C macros for convenience "functions". I've had better luck
> using the macro expansions since there are no macros exported by
> the framework libraries. It's something of a nuisance that Apple's
> documentation generally doesn't tell you that function foo is
> really a macro.
Yeah, I've been "friends" with CFSTR() for a while. ;-) I can't think
of any other non-obvious macros, but it's the most common offender.
(FWIW, the latest documentation for CFString does actually refer to
CFSTR as a macro.) I'm curious as to why Apple made this particular
implementation choice, though ... it seems like CoreFoundation of all
things shouldn't be preprocessor-dependent.
My thought that the problem was related to it being non-published was
rather hasty. The reason only that and #$noErr showed up as problems
was that those are the only two reader-macro references my code uses.
Oops. Duh.
--chris
More information about the Openmcl-devel
mailing list