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: Fred Kiefer
Subject: Re: corebase: use __builtin___CFStringMakeConstantString when available?
Date: Tue, 27 Jun 2017 22:15:57 +0200

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




reply via email to

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