Change a comment so it corresponds to reality. Put back a character that

was previously replaced with a NUL for parsing purposes.  This seems to
fix a very weird parsing bug involving two variable references in the same
value.
This commit is contained in:
Richard Levitte 2005-09-28 18:02:41 +00:00
parent bfa4b8c5ab
commit 23acb0eeb2

View File

@ -613,13 +613,13 @@ static int str_copy(CONF *conf, char *section, char **pto, char *from)
e++;
}
/* So at this point we have
* ns which is the start of the name string which is
* np which is the start of the name string which is
* '\0' terminated.
* cs which is the start of the section string which is
* cp which is the start of the section string which is
* '\0' terminated.
* e is the 'next point after'.
* r and s are the chars replaced by the '\0'
* rp and sp is where 'r' and 's' came from.
* r and rr are the chars replaced by the '\0'
* rp and rrp is where 'r' and 'rr' came from.
*/
p=_CONF_get_string(conf,cp,np);
if (rrp != NULL) *rrp=rr;
@ -638,6 +638,11 @@ static int str_copy(CONF *conf, char *section, char **pto, char *from)
points at. /RL */
len -= e-from;
from=e;
/* In case there were no braces or parenthesis around
the variable reference, we have to put back the
character that was replaced with a '\0'. /RL */
*rp = r;
}
else
buf->data[to++]= *(from++);