On Mon, 11 Mar 2013 08:58:39 +0000, David Chisnall wrote:
On 11 Mar 2013, at 08:39, Luboš Doležel <[email protected]> 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
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
