gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: corebase: use __builtin___CFStringMakeConstantString when available?


From: Ivan Vučica
Subject: Re: corebase: use __builtin___CFStringMakeConstantString when available?
Date: Tue, 27 Jun 2017 22:32:31 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]