[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