[cfe-dev] SourceManger::getBufferData <<INVALID SOURCE LOCATION>>

[Adam T. Moody]

Hello all,
I want to reiterate these questions, since it seems they were missed the 
first time.  I'd appreciate any help.

I'm working with clang version 3.5 (trunk 198970) to create a tool to 
rewrite some source files. I have two questions:

1) Comments for the getEditBuffer method of the Rewriter class suggest 
that it will return the current edit buffer for a file or create and 
return a new buffer if it doesn't already exist. In the case where no 
insert / replace calls have been made, I had hoped this method would 
return the original source, but this doesn't seem to work for me. What 
is the recommended way to get a buffer containing the original source 
when no changes have been made to it?

2) When I have not modified the original source, I get a string like 
"<<<<<INVALID SOURCE LOCATION>>>>>", and in some of those cases, my tool 
seg faults. I wonder if there is a bug in SourceManager::getBufferData. 
The aforementioned string is hardcoded in the function (allocated on the 
stack), and it is used to initialize a StringRef object for the return 
value. Is the returned StringRef object then referencing a portion of 
memory that has been popped from the stack?

Thanks,
-Adam


Moody, Adam T. wrote:

>Hello Clang team,
>
>I'm working with clang version 3.5 (trunk 198970) to create a tool to rewrite some source files.  I have two questions:
>
>
>
>1) Comments for the getEditBuffer method of the Rewriter class suggest that it will return the current edit buffer for a file or create and return a new buffer if it doesn't already exist.  In the case, where no insert / replace calls have been made, I had hoped this method would return the original source, but this doesn't seem to work for me.  What is the recommended way to get a buffer containing the original source when no changes have been made to it?
>
>
>
>2) When I have not modified the original source, I get a string like "<<<<<INVALID SOURCE LOCATION>>>>>", and in some of those cases, my tool seg faults.  I wonder if there is a bug in SourceManager::getBufferData.  The aforementioned string is hardcoded in the function (allocated on the stack), and it is used to initialize a StringRef object for the return value.  Is the returned StringRef object then referencing a portion of memory that has been popped from the stack?
>
>
>
>Thanks for any insight,
>
>-Adam
>  
>