Bug 983 – constant cfstrings for Darwin

When doing Carbon programming for Mac OS X, there are two possible ways to create constant strings for CoreFoundation - both use the CFSTR() macro from CFString.h. It would be nice if the __CFStringMakeConstantString built-in could be made available to D (same as for C/C++), to avoid having to do the runtime call. I've introduced a version(GNU_Constant_CFStrings) that matches the macro __CONSTANT_CFSTRINGS__ that C/C++ uses to check the current setting. But we still need the built-in function for __CFStringMakeConstantString, and I assume that GCC also needs the type somehow (it's a struct pointer, maybe a void* will do) darwin.c: /* struct __builtin_CFString { const int *isa; (will point at int flags; __CFConstantStringClassReference) const char *str; int length; }; */ /* const struct __builtin_CFstring * __builtin___CFStringMakeConstantString (const char *); */

Created attachment 104 gdc-0.23-constant-cfstrings.patch tested OK with gcc-5363

Suggested usage of the built-in would be something like this: /* Macro to allow creation of compile-time constant strings; the argument should be a constant string. CFSTR(), not being a "Copy" or "Create" function, does not return a new reference for you. So, you should not release the return value. This is much like constant C or Pascal strings --- when you use "hello world" in a program, you do not free it. However, strings returned from CFSTR() can be retained and released in a properly nested fashion, just like any other CF type. That is, if you pass a CFSTR() return value to a function such as SetMenuItemWithCFString(), the function can retain it, then later, when it's done with it, it can release it. At this point non-7 bit characters (that is, characters > 127) in CFSTR() are not supported and using them will lead to unpredictable results. This includes escaped (\nnn) characters whose values are > 127. Even if it works for you in testing, it might not work for a user with a different language preference. */ /+ #ifdef __CONSTANT_CFSTRINGS__ #define CFSTR(cStr) ((CFStringRef) __builtin___CFStringMakeConstantString ("" cStr "")) #else #define CFSTR(cStr) __CFStringMakeConstantString("" cStr "") #endif +/ version (GNU_Constant_CFStrings) { private import gcc.builtins; alias __builtin___CFStringMakeConstantString CFSTR; } else { extern(C) CFStringRef __CFStringMakeConstantString(char *cStr); alias __CFStringMakeConstantString CFSTR; } GCC toggles which version it uses with -fconstant-cfstrings (default) or -fno-constant-cfstrings (default in earlier versions of Mac OS X)

Targeted to release 0.24. This should already work, but I neglected to add target builtins to the gcc.builtins module. It may not be a good idea to simply alias to CFSTR in Phobos. The original C CFSTR macro casts the result of the builtin function to CFStringRef, which is defined in the Core Foundation headers.

You mean it would be better to make it an inline function ? CFStringRef CFSTR(char *cStr) { return __builtin___CFStringMakeConstantString(cStr); } Just for type safety, or was there some other reason too ?

Yes, for type safety (compatibility, really). Presumably, a D interface to CoreFoundation is going to define CFString itself, so the wrapper around __CFStringMakeConstantString would also have to be defined in that interface.

The D wrappers I've made so far only used the opaque CFStringRef type, which could be a "typedef void*" or use the struct that C header uses. Will the D inlining work for making data section constants like this ? (I usually try to avoid the inlines, because of the extra object code)

A inline function will not work because the non-inlined original will pass a non-constant char* to __builtin___CFStringMakeConstantString (and fail to compile). Making CFString a void*... alias __builtin___CFStringMakeConstantString CFSTR; alias void * CFStringRef; ... is probably okay except that it becomes possible to this: CFString x = <pointer to something that is not a CFString....> This is another possibility... static if ( is( typeof(__builtin___CFStringMakeConstantString) ret == return ) ) { alias ret CFStringRef; alias typeof(*CFStringRef) CFString; alias __builtin___CFStringMakeConstantString CFSTR; } else { struct CFString; alias CFString * CFStringRef; } ... but typeid(CFStringRef) could differ across object modules depending on the compiler version, flags, etc. We may just have to wait for AST macros to get the perfect solution. (Closing the issue since CFStringMakeConstantString now works.)