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++; e++;
} }
/* So at this point we have /* 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. * '\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. * '\0' terminated.
* e is the 'next point after'. * e is the 'next point after'.
* r and s are the chars replaced by the '\0' * r and rr are the chars replaced by the '\0'
* rp and sp is where 'r' and 's' came from. * rp and rrp is where 'r' and 'rr' came from.
*/ */
p=_CONF_get_string(conf,cp,np); p=_CONF_get_string(conf,cp,np);
if (rrp != NULL) *rrp=rr; if (rrp != NULL) *rrp=rr;
@ -638,6 +638,11 @@ static int str_copy(CONF *conf, char *section, char **pto, char *from)
points at. /RL */ points at. /RL */
len -= e-from; len -= e-from;
from=e; 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 else
buf->data[to++]= *(from++); buf->data[to++]= *(from++);