aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2005-12-26 23:24:09 +0000
committerSimon Tatham <anakin@pobox.com>2005-12-26 23:24:09 +0000
commite15a2defff30a00562800d1b6248a4b65f919e15 (patch)
tree1aba45133b043d54c526f99f0de94b3b535fce78
parent74f45138aeb6608137344c7d5245ff6e3ec12572 (diff)
downloadpuzzles-e15a2defff30a00562800d1b6248a4b65f919e15.zip
puzzles-e15a2defff30a00562800d1b6248a4b65f919e15.tar.gz
puzzles-e15a2defff30a00562800d1b6248a4b65f919e15.tar.bz2
puzzles-e15a2defff30a00562800d1b6248a4b65f919e15.tar.xz
Laurent Thioudellet reports that gcc4's ultra-cautious data flow
warnings require two more variables to be explicitly initialised. In fact these variables are reliably initialised by a subfunction; gcc3 was happy to assume I knew what I was doing when it couldn't prove they were definitely used uninitialised, whereas gcc4 apparently takes the view that the onus is on me to allow it to prove they _aren't_. I regard this as a step backwards, since the effect will be to make explicit initialisation commonplace in cases where the initialiser value is chosen arbitrarily and never expected to be used, at which point (a) it will be less clear which initialisers have genuine purpose and which are compiler-placating fluff, and (b) valgrind's run-time uninitialised-data tracking will become less useful. Still, the effect doesn't seem great as yet, so here's the gcc4-placating checkin. [originally from svn r6508]
-rw-r--r--bridges.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/bridges.c b/bridges.c
index 11397f7..b814a51 100644
--- a/bridges.c
+++ b/bridges.c
@@ -1012,7 +1012,7 @@ static int grid_degree(game_state *state, int x, int y, int *nx_r, int *ny_r)
static int map_hasloops(game_state *state, int mark)
{
- int x, y, ox, oy, nx, ny, loop = 0;
+ int x, y, ox, oy, nx = 0, ny = 0, loop = 0;
memcpy(state->scratch, state->grid, GRIDSZ(state));