[cfe-dev] createCXString reads one past end byte
Argyrios Kyrtzidis
akyrtzi at gmail.com
Wed Jan 23 08:38:35 PST 2013
On Jan 22, 2013, at 11:38 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Tue, Jan 22, 2013 at 9:29 PM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote:
>> On Jan 22, 2013, at 6:49 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>
>>> Hello Argyrios,
>>>
>>> On Mon, Jan 21, 2013 at 9:13 PM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote:
>>>> We could change how CXString works; instead of eagerly malloc'ing in case of a StringRef, have it stored in a "StringRef-kind" form and malloc when clang_getCString is called.
>>>
>>> This will add an extra backing storage mode to CXString, let's call
>>> that CXS_UnmanagedWithLength. In this mode we will store the pointer
>>> in 'data', and length will be stored in the upper bits of
>>> 'private_flags'. But who will own the memory returned by
>>> clang_getCString? We can not change the original CXString from
>>> CXS_UnmanagedWithLength to CXS_Malloc because CXString is a value
>>> type. Or did I misunderstand something?
>>
>> You are right, it is so easy to get a copy of it and trigger a memory leak unintentionally.
>>
>> I'll do some measurements to see if it makes much difference to malloc on every StringRef (in the meantime any suggestions on how to avoid the malloc would be greatly appreciated).
>
> We can add an indirection layer. Let's add a mode CXS_Lazy. 'data'
> would point to a struct:
>
> struct {
> const char *Str;
> unsigned Length:31;
> unsigned IsNulTerminated:1;
> };
>
> Then CXString would remain a value type, and all copies would point to
> the same underlying data.
I like it! We can also enhance the mechanism a bit to be able to use a free list of those so that we avoid malloc'ing them for the normal use pattern of having a CXString as a temporary object to get at the underlying string, what do you think ?
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
More information about the cfe-dev
mailing list