{"thread":{"id":"3831","subject":"[PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables","startedAt":"2006-04-08T15:27:20Z","lastAt":"2006-04-08T17:18:39Z","messageCount":2,"participants":["Marco Roeland","Davide Libenzi"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"18469","messageId":"20060408152720.GA11125@fiberbit.xs4all.nl","threadId":"3831","inReplyTo":null,"subject":"[PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-04-08T15:27:20Z","receivedAt":"2006-04-08T15:27:20Z","isPatch":true,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"Compiling this module gave the following warnings (some double dutch!):\n\nxdiff/xdiffi.c: In functie 'xdl_recs_cmp':\nxdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function\nxdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function\nxdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function\nxdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function\n\nA superficial tracking of their usage, without deeper knowledge about the\nalgorithm, indeed confirms that there are code paths on which these\nvariables will be used uninitialized. In practice these code paths might never\nbe reached, but then these fixes will not change the algorithm. If these\ncode paths are ever reached we now at least have a predictable outcome. And\nshould the very small performance impact of these initializations be\nnoticeable, then they should at least be replaced by comments why certain\ncode paths will never be reached.\n\nSome extra initializations in this patch now fix the warnings.\n\n---\n\n xdiff/xdiffi.c |    5 +++--\n 1 files changed, 3 insertions(+), 2 deletions(-)\n\n0b0bf00d67a66b3ef47862cc51b1d37763f4b99b\ndiff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c\nindex e81bca6..641362d 100644\n--- a/xdiff/xdiffi.c\n+++ b/xdiff/xdiffi.c\n@@ -218,7 +218,7 @@ static long xdl_split(unsigned long cons\n \t\tif (ec >= xenv->mxcost) {\n \t\t\tlong fbest, fbest1, bbest, bbest1;\n \n-\t\t\tfbest = -1;\n+\t\t\tfbest = fbest1 = -1;\n \t\t\tfor (d = fmax; d >= fmin; d -= 2) {\n \t\t\t\ti1 = XDL_MIN(kvdf[d], lim1);\n \t\t\t\ti2 = i1 - d;\n@@ -230,7 +230,7 @@ static long xdl_split(unsigned long cons\n \t\t\t\t}\n \t\t\t}\n \n-\t\t\tbbest = XDL_LINE_MAX;\n+\t\t\tbbest = bbest1 = XDL_LINE_MAX;\n \t\t\tfor (d = bmax; d >= bmin; d -= 2) {\n \t\t\t\ti1 = XDL_MAX(off1, kvdb[d]);\n \t\t\t\ti2 = i1 - d;\n@@ -296,6 +296,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o\n \t} else {\n \t\tlong ec;\n \t\txdpsplit_t spl;\n+\t\tspl.i1 = spl.i2 = 0;\n \n \t\t/*\n \t\t * Divide ...\n-- \n1.3.0.rc3.gad0b\n"},{"id":"18470","messageId":"Pine.LNX.4.64.0604081013480.11852@alien.or.mcafeemobile.com","threadId":"3831","inReplyTo":"20060408152720.GA11125@fiberbit.xs4all.nl","subject":"Re: [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2006-04-08T17:18:39Z","receivedAt":"2006-04-08T17:18:39Z","isPatch":true,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Sat, 8 Apr 2006, Marco Roeland wrote:\n\n> Compiling this module gave the following warnings (some double dutch!):\n>\n> xdiff/xdiffi.c: In functie 'xdl_recs_cmp':\n> xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function\n> xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function\n> xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function\n> xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function\n>\n> A superficial tracking of their usage, without deeper knowledge about the\n> algorithm, indeed confirms that there are code paths on which these\n> variables will be used uninitialized. In practice these code paths might never\n> be reached, but then these fixes will not change the algorithm. If these\n> code paths are ever reached we now at least have a predictable outcome. And\n> should the very small performance impact of these initializations be\n> noticeable, then they should at least be replaced by comments why certain\n> code paths will never be reached.\n\nThese paths are never reached because of the way data is prepared before \nand passed to the function. Unfortunately the compiler cannot know this.\nUsing them as -1 or XDL_LINE_MAX won't help either, since those are out of \ndomain values. You can leave it there and the algo won't suffer, or you \ncan relax a little the warning level when building the file.\n\n\n\n- Davide\n"}]}