[sword-devel] ListKey issue (bug?)

[Troy A. Griffitts]

Yes, as a general rule, you should not count on the return value of a 
const char * persisting after the assignment.

e.g.,  it is alway safe to:

string value = results.getText();
results.<anything>();

it is not necessarily safe to:

const char *value = results.getText();
results.<anything>();


Basically, in this case, results has an internal 'text' value.

getText() returns a pointer to this value.

When you merely assign a pointer, you are now pointing to this internal 
'text' value, so

results++;

will change this memory value, and thus the value pointed to by your 
'retval'.

Anyway, details aside, the general rule is that if you are given a const 
char * as a return value, you should store the contents in your own memory:

 > const char *BackEnd::get_next_listkey(void)
 > {
- 	const char *retval = NULL;
+ 	static SWBuf retval = "";
 > 	
 > 	while(!results.Error()) {
 > 		retval = results.getText();
 > 		results++;
 > 		return retval;
 > 	}
 > 	return NULL;	
 > }

To be threadsafe, you might just want to return SWBuf or std::string 
instead of const char *

Hope this helps.

	-Troy.




Matthew Talbert wrote:
> We ran into an interesting issue with ListKeys. The code in question
> is used in Xiphos to get a list of search results, then iterate
> through them to add to a gui control. I started noticing that
> occasionally, an entry would be junk, ie non-printing characters. We
> traced it down to this portion of code in Xiphos:
> 
> const char *BackEnd::get_next_listkey(void)
> {
> 	const char *retval = NULL;
> 	
> 	while(!results.Error()) {
> 		retval = results.getText();
> 		results++;
> 		return retval;
> 	}
> 	return NULL;	
> }
> 
> So with some debug messages, we were able to determine that retval
> always got the correct text from results.getText(); However, after
> results++, occasionally the text was corrupted. We had several
> confirmations of this error on 64bit machines including 2 using Ubuntu
> JJ 64 bit, and 1 using F10 64 bit. I believe I also saw the problem on
> Ubuntu HH 32 bit, however no one else was able to replicate the
> problem on 32 bit, so my experience may have been something else.
> 
> To work around this, we are using code like this:
> 
> const char *BackEnd::get_next_listkey(void)
> {
> 	static char retval[128];
> 	const char *test = NULL;
> 	
> 	while(!results.Error()) {
> 		(void) g_strlcpy(retval, results.getText(), 126);
> 		test = results.getText();
> 		results++;
> 		GS_message((test));
> 		return retval;
> 	}
> 	return NULL;	
> }
> 
> GS_message((test)) just prints the value of test, which is how we
> determined that results++ was changing it somehow. I was able to
> reproduce this consistently searching for "God" in EMTV, although
> every module I tried had intermittent failures.
> 
> Matthew
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page