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: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
