aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorIan Jackson <Ian.Jackson@eu.citrix.com>2011-03-03 17:11:31 +0000
committerIan Jackson <Ian.Jackson@eu.citrix.com>2011-03-03 17:11:31 +0000
commit3860f61cd10fe878bbb792b7ebb9e2d186589d37 (patch)
treeab17e36261e9e9595da68effc55aba326c6820c9
parentbaae0f2bceb661804de10ec428d2d175fa2ec632 (diff)
downloadxen-3860f61cd10fe878bbb792b7ebb9e2d186589d37.tar.gz
xen-3860f61cd10fe878bbb792b7ebb9e2d186589d37.tar.bz2
xen-3860f61cd10fe878bbb792b7ebb9e2d186589d37.zip
libxl: correctly initialise yylineno
Sometimes xl would read an uninitialised variable when printing error messages, resulting in things like this: /etc/xen/thing.cfg:1030057088: config parsing error near `"ws08r2-x64-2': lexical error This is because yylineno is a variable inside the scanner created by yylex_init, but it is not initialised by yylex_init. (Debian bug #616099.) On the way I discovered a lot of complication to do with the calling convention between bison and flex in reentrant parsers/scanners which use locations (Debian bug #616100) but as the above change makes the current code in xen-unstable work I don't propose to do anything else about that now in our tree. Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Tested-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
-rw-r--r--tools/libxl/libxlu_cfg.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 663fdf9a02..f947c219b4 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -43,6 +43,9 @@ static void ctx_dispose(CfgParseContext *ctx) {
static void parse(CfgParseContext *ctx) {
/* On return, ctx.err will be updated with the error status. */
int r;
+
+ xlu__cfg_yyset_lineno(1, ctx->scanner);
+
r= xlu__cfg_yyparse(ctx);
if (r) assert(ctx->err);