[Top][All Lists]

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

Re: Implementing CFSTR() in corebase

From: Stef Bidi
Subject: Re: Implementing CFSTR() in corebase
Date: Fri, 22 Jan 2010 11:41:17 -0600

On Fri, Jan 22, 2010 at 11:16 AM, Richard Frith-Macdonald <address@hidden> wrote:
However, as I understand it, the idea is that this (corebase) should be built on top of GNUstep-base, so as we know it's always going to be linked with the base library, it might be possible to take advantage of the fact that we know that the base library defines NSConstantString as the class for constant strings, and get the compiler to initialise the 'isa' field with the appropriate external reference for the linker to fixup at runtime.  You would need to look into that (ask someone who knows more about low level compiler/linker stuff than me) to find out if it's really possible.
I was hoping to take advantage of exactly that!  I'll go ahead and share Fred's test (see attached files).  In this case, the NSConstantString struct is compiled with {NULL, "myString", 8} (makes sense)... it's also in the .date section (r/w) and not .rodate (r).  At some points that NULL gets turned into a pointer to the NSConstantString class, and that's what I'd like to be able to reproduce, if at all possible.
Another issue is the reference counting.  GNUstep objects include a header that has a NSZone * and integer for reference counting... does this need to be reproduced.
Would setting CFSTR() to a function allow it to work in initializer?
PS: I was hoping to come up with a solution that is at least halfway decent without "requiring" compiler support (I don't have a new compiler to test it with).

Attachment: const.s
Description: Binary data

Attachment: const.m
Description: Binary data

reply via email to

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