Re: CoreBase toll-free bridging

[Stefan Bidi]

Having the compiler output a compatible structure would be nice, but
I'm not sure how realistic it is to depend on it.  Until recently,
GNUstep still support GCC 2.95 and just recently move to minimum GCC
4.0.  If this charge were to be done, we'd be having to support two
completely incompatible structures (they aren't backward compatible
because of the CFTypeID variable in between the isa and string
pointer) for at least another 6 years.

My preference, would be to do one of two things:
(1) As David points out, GNUstep already replaces instances of
NSConstantString with GSString.  The way I understand the code there,
GSString can have any internal structure and isn't dependent on the
compiler's output.
(2) Use a much more efficient hash algorithm than the one-at-a-time
function that we currently use.  Jenkins' lookup3 and SpookyHash are
both much more efficient, for example.  Using a faster hash function
would allow GNUstep to not need to replace the class instance.

As for the collection class issue, check this sample code from Apple
that MUST be supported
(https://developer.apple.com/library/mac/#samplecode/Dictionary/Introduction/Intro.html#//apple_ref/doc/uid/DTS40008855).
 They use actual numbers as the keys.  At one point I actually had
this example running, despite not having the desired output because of
the need for CFPropertyList (currently unimplemented).

As for the Clang's built-in function for CFStrings, it outputs a
NSConstantString-like structure.  I remember having a few problems
with it (NSConstantString wasn't initialized by the time I had to use
the strings) and decided to comment out that code for a while until I
got a few other things sorted out.  Eventually, I removed it
altogether.  Adding it back isn't a problem, but that piece of code
just won't work with the way CoreBase is currently set up.

On Mon, Mar 11, 2013 at 4:22 AM, Luboš Doležel <address@hidden> wrote:
> On Mon, 11 Mar 2013 08:58:39 +0000, David Chisnall wrote:
>>
>> On 11 Mar 2013, at 08:39, Luboš Doležel <address@hidden> wrote:
>>
>>> Sure. This is what CFString's struct looks like now (I replaced internal
>>> types with what everyone understands):
>>>
>>> stuct __CFString
>>> {
>>>    void* isa; // for ObjC support
>>>    int16_t typeID; // CF type ID - we need to make CFString's typeID
>>> constant forever (now it could randomly change)
>>>    struct
>>>    {
>>>        int16_t ro:1; // always set to 1 for constant strings
>>>        int16_t reserved:7;
>>>        int16_t info:8; // probably only "hasnull" (0x10) for constant
>>> strings
>>>    };
>>>    void* data;
>>>    uint32_t length;
>>>    uintptr_t hashCode;
>>> };
>>>
>>> Is this layout something you'd accept as the next constant NSString?
>>
>>
>> I'd recommend that we have a couple of bits in the flags set for
>> encoding, to allow ASCII or UTF-8 (ASCII implies no multibyte
>> characters, so character-index lookups are easier).  If we're going to
>> have to live with this for a long time, then it might be interesting
>> for variable-length encodings to have a map from character indexes to
>> byte indexes.
>>
>> I'd rather not have a C bitfield in the definition, because its
>> layout is very ABI-specific: An int16_t with fixed bit definitions is
>> much easier to work with.
>
>
> The only hard requirement for CF is the CF type ID field, so whatever you
> consider appropriate...
>
>
>> The other question is how we initialise the isa pointer.  With recent
>> libobjc2 / clang, class pointers are exposed as public symbols, so we
>> could just make a weak reference to the class, but that would break if
>> GNUstep-base is compiled with gcc.
>
>
> The macosx ObjC ABI uses a reference to ___CFConstantStringClassReference,
> which is a copy of an arbitrary struct objc_class (typically provided and
> filled in by CF on startup).
> So once you start using @"aaa" or CFSTR("aaa"), you need to link against
> something that provides this symbol.
>
> For GCC, do you think keeping the old layout around without any new features
> just for GCC would be an option?
>
>
>> Alternatively, we could create the normal call to __objc_exec_class()
>> in the constructor, but make __objc_exec_class weak and only call it
>> if it is non-zero.  This would impose a small startup cost on every
>> compilation unit containing CF strings.
>>
>> Additionally, for short ASCII strings, I'd like to make clang emit
>> GSTinyString instances (strings hidden in pointers) on 64-bit
>> platforms.  Do you think that this would be a problem for CF?
>
>
> I'd certainly have to write a few unit tests to avoid any loose ends, but it
> should be possible.
>
>
>>> Which one exactly? CFSTR() in corebase expands to a regular function
>>> call.
>>
>>
>> Really?  I remember adding support for
>> __builtin___NSStringMakeConstantString() a while ago...
>
>
> I've found your e-mails, but there is no reference to such builtins in
> corebase.
> Anyway, what struct does it emit? Unless it matches the current layout of
> struct __CFString, it wouldn't work anyway.
>
> --
> Luboš Doležel
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev