[cfe-dev] Proposal for solving C string lifetime problem with clang_getDeclSpelling()/Selector::getAsString()

[steve naroff]

On Nov 6, 2009, at 2:35 PM, Fariborz Jahanian wrote:

>
> On Nov 6, 2009, at 11:26 AM, steve naroff wrote:
>
>>
>> On Nov 6, 2009, at 2:19 PM, Fariborz Jahanian wrote:
>>
>>>
>>> On Nov 6, 2009, at 11:14 AM, steve naroff wrote:
>>>
>>>> Hi John,
>>>>
>>>> I just spoke with Doug about this and we came up with the following
>>>> proposal...
>>>>
>>>> The following API would now return a CXString;
>>>>
>>>> CINDEX_LINKAGE CXString clang_getDeclSpelling(CXDecl);
>>>>
>>>> The interface to CXString would be:
>>>>
>>>> const char *clang_getCString(CXString);
>>>> void clang_disposeString(CXString); /* client must always call this
>>>> when it no longer needs the string */
>>>>
>>>> The implementation of CXString would be:
>>>>
>>>> /* Note that both of these slots are effectively 'private' */
>>>> typedef struct {
>>>> const char *Spelling;
>>>> /* A 1 value indicates the clang_ indexing API needed to allocate
>>>> the string (and it must be freed by clang_disposeString()). */
>>>> int MustFreeString;
>>> Is there need for API for getting/setting MustFreeString?
>>>
>>
>> Nope...that's why I mentioned both slots are private (i.e. they are  
>> only set internally...in this instance, by clang_getDeclSpelling()).
>
> Actually you mentioning private brought up the question. You have  
> clang_getCString for, I assume, accesing, Spelling?
>

Yes. That means Spelling is conceptually private (since there is an  
API to retrieve it). Since we are dealing with C, the public/private  
issues isn't a big deal. The point was CXString should be treated as  
an opague struct that can be manipulated with the 2 hooks mentioned.  
The implementation of the clang_ functions would manage the slots  
directly (which is why there are no setters/getters in the public C  
API).

snaroff

> - fariborz
>
>>
>>
>> snaroff
>>
>>> - Fariborz
>>>
>>>>
>>>> } CXString;
>>>>
>>>> The benefit of this abstraction is we can use it in other places if
>>>> necessary (when dealing with string lifetime issues that cross  
>>>> the C/C+
>>>> + language barrier).
>>>>
>>>> What do you (or others interested in this) think? From my  
>>>> perspective,
>>>> it seems cleaner than the other proposals that have been discussed.
>>>>
>>>> If we can agree on the change, are you interested in making this  
>>>> change?
>>>>
>>>> Thanks much,
>>>>
>>>> snaroff
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>