Re: corebase: use __builtin___CFStringMakeConstantString when available?

[Fred Kiefer]

Any workaround that lets you keep on going should be good enough. I think a 
proper solution would be to replace the class structure at 
__CFConstantStringClassReference on program load time with the constant string 
class from GNustep base if that is present. If it isn’t, the only way to go is 
to have all the checks you mention.

For your GSoC project relying on Objective-C strings definitely is the way to 
go.

Fred



> Am 28.06.2017 um 02:19 schrieb Daniel Ferreira (theiostream) <address@hidden>:
> 
> Hmm, bad news about this.
> 
> Here's the commit that enables this feature on CoreBase, for some
> context on what I'll discuss next:
> https://github.com/theiostream/corebase/commit/98d799a6de056f1b99fa9a218a0f354f613ba578.
> 
> Sadly, simply switching CFSTR() from __CFStringMakeConstantString() to
> __builtin___CFStringMakeConstantString() doesn't just work
> out-of-the-box. Both clang and gcc generate, out of that builtin, a
> struct that "fits" into CFStringRef's spec, but there is one tricky
> detail. Its "isa" member is set on compile-time to a pointer tracked
> by the __CFConstantStringClassReference symbol.
> 
> The symbol itself would not be a problem. We could just point it on
> compile-time to null bytes and pretend that never existed (as Apple
> seems to do on CFLite). But CoreBase totally relies on that "isa"
> member having something meaningful, and it'll pretty much always
> forward that null "isa" to libobjc2 to try to figure out the CFType of
> that constant string. This broken "isa" will crash libobjc2.
> 
> That said, I need a way to place a valid Objective-C class definition
> in that symbol on compile-time (probably it'd be an empty subclass of
> NSCFString), but I'm totally unaware of any way to do that. Or maybe
> make that point to an ordinary _OBJC_CLASS_* symbol somehow. Any
> hints?
> 
> Otherwise, the other way I can see to implement this is to check if
> the "isa" member is a pointer to __CFConstantStringClassReference
> every time we try to do something with it. But that'd require a bunch
> of changes to CoreBase, Base, and would likely leave behind a lot of
> bugs, so I'm really not into this.
> 
> Also, Apple's "workaround" on CFLite and CFNetwork for compilers that
> don't support this builtin is to simply build the CFString struct by
> hand -- still relying on __CFConstantStringClassReference as an isa.
> So that'd break CoreBase as well.
> 
> If we choose not to implement this right now due to the complexity
> being too large, I suppose I *can* export these constant strings as
> Objective-C string literals. But it'd still be weird for a CF-only
> library to rely on ObjC to export its CFStringRefs. :(
> 
> -- Daniel.
> 
> On Tue, Jun 27, 2017 at 6:32 PM, Ivan Vučica <address@hidden> wrote:
>> The test should be done similarly, though: test for the feature rather
>> than the compiler.
>> 
>> On Tue, Jun 27, 2017 at 9:15 PM, Fred Kiefer <address@hidden> wrote:
>>> I agree that we should add this feature, but from looking at the actual 
>>> code I don’t think it will help us.
>>> The feature seems to be only present in gcc on Darwin with the Next, that 
>>> is old Apple ObjC, runtime. We should rather be looking for a way to 
>>> convince the gcc people to enable this on more platforms.
>>> This shouldn’t be much of a limitation for Daniel as he will be using clang 
>>> anyway.
>>> 
>>> Fred
>>> 
>>> 
>>>> Am 27.06.2017 um 19:34 schrieb Ivan Vučica <address@hidden>:
>>>> 
>>>> It seems sane, and you should update corebase's autoconf to detect 
>>>> presence of this compiler built-in.
>>>> 
>>>> That is: an installed header should be generated and contain a constant 
>>>> describing whether CFStringMake...() is present.
>>>> 
>>>> On June 27, 2017 5:32:04 PM GMT+01:00, "Daniel Ferreira (theiostream)" 
>>>> <address@hidden> wrote:
>>>> Hi,
>>>> 
>>>> I'm currently working on developing a CoreFoundation-based library
>>>> with CoreBase, and I just realized that unlike in OSX, CFSTR() does
>>>> not generate a compile-time CFStringRef constant.
>>>> 
>>>> This is fine compatibility-wise since CFSTR() does not guarantee that
>>>> it will do so -- in fact, Apple's own CoreFoundation headers check if
>>>> we are on Linux and if that is the case, it does not enable this
>>>> compile-time feature.
>>>> 
>>>> However, as far as my (extremely brief) investigation went we can
>>>> generate compile-time CFStringRefs using
>>>> __builtin___CFStringMakeConstantString(), which is present since this
>>>> gcc commit[1] and since forever in clang. So it makes sense to me that
>>>> this should not be platform-dependent, but rather compiler-dependent.
>>>> 
>>>> This helps because I need to export some CFStringRefs as symbols in a
>>>> new lib for WebKit compatibility, and without this feature I'd be left
>>>> with the option to either:
>>>> a) create an Objective-C file in a C-only library just for exporting 
>>>> NSStrings;
>>>> b) make a bizarre __attribute__((constructor))-like thing to
>>>> initialize the constant strings onto the symbols on library load.
>>>> 
>>>> Does this seem sane? If so, I need a tip in how to guard for this
>>>> builtin in gcc.
>>>> 
>>>> -- Daniel.
>>>> 
>>>> [1]: 
>>>> https://github.com/gcc-mirror/gcc/commit/d4238e8bcce578381de9480d78a651830a8f9754,
>>>> looks like it was added in gcc 5.3.
>>>> 
>>>> 
>>>> Gnustep-dev mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>> 
>>>> --
>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>> _______________________________________________
>>>> Gnustep-dev mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>> 
>>> 
>>> _______________________________________________
>>> Gnustep-dev mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>> 
>> _______________________________________________
>> Gnustep-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev