{
 "tokens": {
  "input": 127314,
  "cache_read": 52452,
  "cache_write": 1692,
  "output": 20002
 },
 "reviews": [
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/a/allegro4.4/allegro4.4_4.4.3.1.orig.tar.gz",
    "main allegro-4.4.3.1/addons/allegrogl/src/win.c:1540:37: error: Uninitialized variable: lock_time [uninitvar]\n     allegro-4.4.3.1/addons/allegrogl/src/win.c:1538:7: note: Assuming condition is true\n     allegro-4.4.3.1/addons/allegrogl/src/win.c:1540:37: note: Uninitialized variable: lock_time"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 1540, `&lock_time` is passed to SystemParametersInfo, which writes the value into it. Nothing reads the uninitialized variable here, so the uninitvar report is a false positive in both versions. The PR only lowers its severity from error to warning, because the value depends on a condition (\"Assuming condition is true\"). The false positive is still there, but it is no longer flagged as a definite error, which is slightly better for users and matches the PR's intent."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/a/allegro4.4/allegro4.4_4.4.3.1.orig.tar.gz",
    "your allegro-4.4.3.1/addons/allegrogl/src/win.c:1540:37: warning: Uninitialized variable: lock_time [uninitvar]\n     allegro-4.4.3.1/addons/allegrogl/src/win.c:1538:7: note: Assuming condition is true\n     allegro-4.4.3.1/addons/allegrogl/src/win.c:1540:37: note: Uninitialized variable: lock_time"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "Line 1540 passes `&lock_time` to `SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, ...)`, which writes the current timeout into it. Taking the address of an uninitialized variable to hand it to an output parameter is not a read, so this report is a false positive both before and after the change. The pull request only lowers the severity from error to warning because the value depends on the assumed condition at line 1538 (`if (fullscreen)`). That matches the PR's intent. The bogus report itself remains, so this is not a real improvement, though a false positive as a warning is slightly less harmful than as an error."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/d/dds/dds_2.9.0.orig.tar.gz",
    "main dds-2.9.0/src/Scheduler.cpp:737:14: error: Uninitialized variable: st.repeatOf [uninitvar]\n     dds-2.9.0/src/Scheduler.cpp:728:9: note: Assuming condition is true\n     dds-2.9.0/src/Scheduler.cpp:732:19: note: Assuming condition is true\n     dds-2.9.0/src/Scheduler.cpp:737:14: note: Uninitialized variable: st.repeatOf"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "In `GetNumber`, `st` is a local `schedType`. On the early-return path (`g == -1` and `currGroup >= numGroups - 1`), only `st.number` is set, so `st.repeatOf` is returned uninitialized. The finding itself is legitimate and still reported. Only the severity changes, from error to warning. The path depends on two assumed conditions, as the error path notes say. Cppcheck normally uses warning severity for findings that depend on such assumptions. Callers also likely check `number == -1` and ignore `repeatOf`. Warning severity is therefore more accurate, which fits the PR's intent."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/d/dds/dds_2.9.0.orig.tar.gz",
    "your dds-2.9.0/src/Scheduler.cpp:737:14: warning: Uninitialized variable: st.repeatOf [uninitvar]\n     dds-2.9.0/src/Scheduler.cpp:728:9: note: Assuming condition is true\n     dds-2.9.0/src/Scheduler.cpp:732:19: note: Assuming condition is true\n     dds-2.9.0/src/Scheduler.cpp:737:14: note: Uninitialized variable: st.repeatOf"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "The finding is unchanged; only its severity drops from error to warning. `st` is a local `schedType`. On the early-return path at line 737, only `st.number` is set, so `st` is returned with `st.repeatOf` uninitialized. That path is reached only when both `g == -1` (line 728) and `currGroup >= numGroups - 1` (line 732) hold, which is what the error path's 'Assuming condition is true' notes say. Cppcheck's convention is to report 'error' for bugs that always happen when the code runs, and 'warning' for bugs that depend on conditions. The diagnostic is still reported with the same error path, so users lose nothing, and the warning severity now matches that convention."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForBool.c:354:40: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForBool.c:345:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForBool.c:354:40: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 354, `&data` is passed to `XtGetSubresources`, which fills `data` as an output parameter. The `else` branch initializes `data` field by field. So `data` is never read uninitialized, and the uninitvar report is a false positive both before and after the PR. The PR only changes the severity from error to warning because the value depends on the condition at line 345. The false positive remains, but it is no longer shown as a definite error, which reduces its impact for users who filter by severity. This is a small benefit, so the confidence is low."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForFile.c:231:39: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForFile.c:225:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForFile.c:231:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "Line 231 passes `&data` to `XtGetSubresources`, an output function that fills the struct, so `data` is not read uninitialized. The else branch also initializes every field. The warning is a false positive either way. The PR does not remove it; it only lowers its severity from error to warning because the value depends on the condition at line 225. A false positive that remains is less harmful as a warning than as an error. The change is therefore a minor improvement, and the false positive itself is still there."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForItem.c:193:39: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForItem.c:182:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForItem.c:193:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "`data` is passed by address to `XtGetSubresources()`, which fills it in, so this uninitvar report is a false positive in both versions. The PR does not remove it. It only lowers the severity from error to warning, because the value depends on the `dialog_name != NULL` condition (the 'Assuming condition is true' note). A false positive reported as a warning rather than an error is slightly less harmful, and it matches the intent of the PR. The underlying false positive remains, so the benefit is small."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForString.c:304:39: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForString.c:300:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForString.c:304:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 304, `&data` is passed to `XtGetSubresources()`, which writes the resource values into the struct. Its uninitialized contents are never read, so the uninitvar report is a false positive either way. The PR does not remove the report; it only lowers its severity from error to warning because the value depends on the assumed condition at line 300. A wrong report shown as a warning is less harmful than one shown as an error (for example, it no longer fails builds that gate on errors). That makes this a minor improvement, but the false positive itself remains."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Create.c:168:40: error: Uninitialized variable: requires_string [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Create.c:167:9: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Create.c:168:40: note: Uninitialized variable: requires_string"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "`requires_string` is passed by address, as `(XtPointer)&requires_string`, to `XtGetSubresources`. That call writes the resource value into it before line 172 reads it. So the uninitvar report at line 168 is a false positive with either severity. The PR only lowers it from error to warning because the value depends on the condition `load`. The bogus report is still there, just less prominent, so the change hardly matters to users here."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/MsgDialogs.c:432:39: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/MsgDialogs.c:427:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/MsgDialogs.c:432:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`XtGetSubresources(shell, (XtPointer)&data, ...)` takes the address of `data` and fills it in. This is the standard Xt way to initialize a struct. So the warning is a false positive either way. The PR downgrades it from error to warning because the value is only conditional (the `if (dialog_name != NULL)` branch). That makes the severity more accurate and makes this false positive less severe."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Working.c:130:39: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Working.c:125:9: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Working.c:130:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 130, `&data` is passed to `XtGetSubresources`, which fills the struct as an output parameter. Reading `data` there is not a use of an uninitialized value, so the warning is a false positive either way. The PR only changes the severity: the uninitialized value depends on the condition (`dialog_name`), so it is now reported as a warning instead of an error. The false positive remains, but it is less severe, and the severity now matches the PR's intent for conditional values. This is a small improvement."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/clients/qmon/AskForItems.c:446:44: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/clients/qmon/AskForItems.c:442:20: note: Assuming condition is true\n     sge-8.1.9/source/clients/qmon/AskForItems.c:446:44: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 446, `&data` is passed to XtGetSubresources(), which fills the struct with resource values. `data` is an output buffer, so it is not being read uninitialized, and the warning is a false positive either way. The PR only lowers the severity from error to warning, because the value depends on the condition 'dialog_name != NULL'. A false positive reported as a conditional warning is less harmful to users than a hard error. So this is a small improvement, though the underlying false positive is still there."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/clients/qmon/AskForTime.c:645:45: error: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/clients/qmon/AskForTime.c:641:21: note: Assuming condition is true\n     sge-8.1.9/source/clients/qmon/AskForTime.c:645:45: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "Line 645 passes `&data` to `XtGetSubresources`, which fills the struct; the else branch initializes the fields directly. Taking the address of an uninitialized struct for an output parameter is not an uninitialized read, so the warning is a false positive both before and after the PR. The PR only lowers the severity from error to warning because the value depends on a condition. The false positive stays, so users see essentially no difference."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "main sge-8.1.9/source/utilbin/windows/qloadsensor/pdhservice.c:120:45: error: Uninitialized variable: buffer [uninitvar]\n     sge-8.1.9/source/utilbin/windows/qloadsensor/pdhservice.c:117:18: note: Assuming condition is true\n     sge-8.1.9/source/utilbin/windows/qloadsensor/pdhservice.c:120:45: note: Uninitialized variable: buffer"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "`buffer` is never read uninitialized here. Its address is passed as an output argument to `RegQueryValueEx`, which writes the DWORD value into it. So the report is a false positive in both versions. The PR only changes the severity: the value comes from a condition (\"Assuming condition is true\"), so it is reported as a warning instead of an error. A conditional finding is more accurately a warning, and a false positive at warning severity is less harmful than at error severity. The change is a small improvement, though the underlying false positive remains."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForBool.c:354:40: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForBool.c:345:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForBool.c:354:40: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "At line 354, `&data` is passed to `XtGetSubresources`, which writes the resource values into `data`. It is an output argument, not a read of an uninitialized variable. The `else` branch initializes `data` explicitly, so it is initialized on both paths. The report is a false positive both before and after the PR. The PR only lowers its severity from error to warning because the value depends on a condition ('Assuming condition is true'). Users still get the same wrong report, so the change barely matters here."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForFile.c:231:39: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForFile.c:225:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForFile.c:231:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 231 the code passes `&data` to `XtGetSubresources`, which fills the struct with resource values. Taking the address of an uninitialized struct to pass it as an output buffer is not an uninitialized read, so this report is a false positive in both versions. The PR only lowers the severity from error to warning because the uninit value depends on the condition at line 225 (`dialog_name != NULL`). The false positive remains, but a lower severity better reflects the uncertainty and makes it less harmful. That is a small improvement in message accuracy, not a real fix."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForItem.c:193:39: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForItem.c:182:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForItem.c:193:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 193, `&data` is passed to `XtGetSubresources`, an Xt function that fills the struct from resources. `data` is an output argument here, not a read of uninitialized memory, so the warning is a false positive both before and after the PR. The PR only lowers its severity from error to warning, because the value depends on a condition (\"Assuming condition is true\"). A false positive reported as a warning misleads users less than one reported as an error, so this is a small improvement. The underlying false positive remains."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForString.c:304:39: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForString.c:300:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/AskForString.c:304:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 304, `&data` is passed to XtGetSubresources, which fills the struct as an output parameter. Taking the address of the uninitialized struct is not a read, so the uninitvar report is a false positive both before and after the PR. The PR only lowers its severity from error to warning, because the value is marked conditional (\"Assuming condition is true\"). The false positive stays, but it is now less prominent, which is slightly better for users."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Create.c:168:40: warning: Uninitialized variable: requires_string [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Create.c:167:9: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Create.c:168:40: note: Uninitialized variable: requires_string"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "The flagged token is `&requires_string`, passed as an output buffer to `XtGetSubresources`, which writes the resource value into it. Taking the address of an uninitialized variable to receive output is not an uninitialized read, so this is a false positive either way. The PR only lowers its severity from error to warning because the value is marked conditional (the `if (load)`). It is still a wrong report, so the change makes no meaningful difference to users."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/MsgDialogs.c:432:39: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/MsgDialogs.c:427:21: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/MsgDialogs.c:432:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "At line 432 the code passes `&data` to XtGetSubresources, which fills in the struct. Data is not read here, so the uninitvar report is a false positive. The PR only lowers the severity from error to warning for values that depend on a condition. The warning is still wrong, but a false positive marked as warning misleads users less than one marked as error, so the change is a small improvement."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Working.c:130:39: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Working.c:125:9: note: Assuming condition is true\n     sge-8.1.9/source/3rdparty/qmon/Xmt310/Xmt/Working.c:130:39: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "At line 130, `&data` is passed to `XtGetSubresources()`, which fills `data` in as an output parameter. Taking the address is not a read of uninitialized memory, so this is a false positive in both versions. The PR only lowers the severity from error to warning because the value depends on a condition. The bogus report is still there, so for users the change makes little difference."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/clients/qmon/AskForItems.c:446:44: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/clients/qmon/AskForItems.c:442:20: note: Assuming condition is true\n     sge-8.1.9/source/clients/qmon/AskForItems.c:446:44: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "At line 446, `&data` is passed to `XtGetSubresources`, which fills the struct with resource values. Passing the address of an uninitialized struct to an output function is not a read, so this report is a false positive in both versions. The PR only lowers the severity from error to warning because the value depends on the assumed condition `dialog_name != NULL`. That matches the PR's intent, but the report itself is still wrong. Users still see the same false positive, just at a lower severity, so the change is essentially neutral."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/clients/qmon/AskForTime.c:645:45: warning: Uninitialized variable: data [uninitvar]\n     sge-8.1.9/source/clients/qmon/AskForTime.c:641:21: note: Assuming condition is true\n     sge-8.1.9/source/clients/qmon/AskForTime.c:645:45: note: Uninitialized variable: data"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "Line 645 passes `&data` to `XtGetSubresources`, which fills the struct, and the else branch initializes the fields directly. So `data` is not read uninitialized here, and the warning looks like a false positive either way. The PR only lowers the severity from error to warning, because the value depends on the assumed condition `dialog_name != NULL`. That reflects the conditional nature of the finding more accurately and makes this false positive less severe, so it is a small improvement."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz",
    "your sge-8.1.9/source/utilbin/windows/qloadsensor/pdhservice.c:120:45: warning: Uninitialized variable: buffer [uninitvar]\n     sge-8.1.9/source/utilbin/windows/qloadsensor/pdhservice.c:117:18: note: Assuming condition is true\n     sge-8.1.9/source/utilbin/windows/qloadsensor/pdhservice.c:120:45: note: Uninitialized variable: buffer"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "At line 120, `&buffer` is passed to `RegQueryValueEx`, which is an output parameter that writes `buffer`. Taking the address of an uninitialized variable for an out-parameter is not a read, so this report is a false positive both before and after the PR. The PR only lowers the severity from error to warning, because the value depends on the condition at line 117 being true. That severity matches the conditional nature of the finding, and a false positive shown as a warning is less harmful than one shown as an error. The false positive itself remains, so the gain is small."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/s/snap7/snap7_1.4.2+dfsg.orig.tar.xz",
    "main snap7-full-1.4.2/src/core/s7_micro_client.cpp:947:16: error: Uninitialized variable: BI.MC7Size [uninitvar]\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:944:15: note: Assuming condition is true\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:947:16: note: Uninitialized variable: BI.MC7Size"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "`BI` is filled indirectly: `Job.pData=&BI` is set, and `opAgBlockInfo()` writes through that pointer when it returns 0. So reading `BI.MC7Size` inside `if (Result==0)` is not really uninitialized, and the warning is a false positive. Cppcheck does not track this aliasing. The PR does not remove the report; it reports it as `warning` instead of `error`, because the value only holds after 'Assuming condition is true'. Lowering a condition-dependent false positive from error to warning makes it less prominent and is more consistent with what Cppcheck actually knows, so this is a mild improvement."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/s/snap7/snap7_1.4.2+dfsg.orig.tar.xz",
    "main snap7-full-1.4.2/src/core/s7_micro_client.cpp:986:24: error: Uninitialized variable: BI.MC7Size [uninitvar]\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:984:15: note: Assuming condition is true\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:986:24: note: Uninitialized variable: BI.MC7Size"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "`BI` is filled indirectly: its address is stored in `Job.pData` and then `opAgBlockInfo()` writes to it. Reading `BI.MC7Size` when `Result==0` is therefore almost certainly fine, and the report looks like a false positive either way. The finding only arises by 'assuming condition is true' at line 984, so the uninit value is conditional and should not be a certain error. The PR lowers it from error to warning. The finding is still there, but its severity now fits the uncertainty better, which is a small improvement."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/s/snap7/snap7_1.4.2+dfsg.orig.tar.xz",
    "your snap7-full-1.4.2/src/core/s7_micro_client.cpp:947:16: warning: Uninitialized variable: BI.MC7Size [uninitvar]\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:944:15: note: Assuming condition is true\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:947:16: note: Uninitialized variable: BI.MC7Size"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "The code stores `&BI` in `Job.pData`, then calls `opAgBlockInfo()`, which fills the block info (including `MC7Size`) through that pointer. When `Result==0`, `BI.MC7Size` is therefore initialized, so this report is a false positive in both versions. The PR only lowers the severity from error to warning, because the value depends on an assumed condition. That makes the message less alarming and consistent with its conditional basis, a mild improvement. The underlying false positive remains."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/s/snap7/snap7_1.4.2+dfsg.orig.tar.xz",
    "your snap7-full-1.4.2/src/core/s7_micro_client.cpp:986:24: warning: Uninitialized variable: BI.MC7Size [uninitvar]\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:984:15: note: Assuming condition is true\n     snap7-full-1.4.2/src/core/s7_micro_client.cpp:986:24: note: Uninitialized variable: BI.MC7Size"
   ],
   "verdict": {
    "verdict": "neutral",
    "confidence": "medium",
    "explanation": "`BI` is a local `TS7BlockInfo` whose address is stored in `Job.pData` before `opAgBlockInfo()` is called. That function fills the struct through `Job.pData`, and `Result==0` means it succeeded. So `BI.MC7Size` is initialized at line 986, and the uninitvar report is a false positive in both versions. Cppcheck simply does not track the write through the member pointer. The PR only lowers the severity from error to warning because the value path involves an assumed condition. The false positive is still reported, so the change makes little practical difference to users."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/w/wxwidgets3.2/wxwidgets3.2_3.2.11+dfsg1.orig.tar.xz",
    "main wxWidgets-3.2.11/src/motif/xmcombo/xmcombo.c:3154:70: error: Uninitialized variables: data.item_internal, data.result [uninitvar]\n     wxWidgets-3.2.11/src/motif/xmcombo/xmcombo.c:3149:10: note: Assuming condition is true\n     wxWidgets-3.2.11/src/motif/xmcombo/xmcombo.c:3154:70: note: Uninitialized variables: data.item_internal, data.result"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "The PR only changes severity: values reached through an 'Assuming condition is true' path are now reported as warnings instead of errors. The finding itself is doubtful. `&data` is passed as an opaque `XtPointer` to `XtCallCallbacks` for the XmOP_INIT operation. The user callback is probably expected to fill fields such as `item_internal`, and `result` is set before the compare calls. So reading the uninitialized fields is unlikely to be a real bug. Downgrading a probable false positive from error to warning, as the PR intends for conditional values, is a modest gain for users."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/w/wxwidgets3.2/wxwidgets3.2_3.2.11+dfsg1.orig.tar.xz",
    "your wxWidgets-3.2.11/src/motif/xmcombo/xmcombo.c:3154:70: warning: Uninitialized variables: data.item_internal, data.result [uninitvar]\n     wxWidgets-3.2.11/src/motif/xmcombo/xmcombo.c:3149:10: note: Assuming condition is true\n     wxWidgets-3.2.11/src/motif/xmcombo/xmcombo.c:3154:70: note: Uninitialized variables: data.item_internal, data.result"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "The only change is the severity, from error to warning, matching the PR's intent that values reached through a condition ('Assuming condition is true') are not reported as certain errors. The code fills some fields of `data` and passes `&data` to `XtCallCallbacks`. For `XmOP_INIT`, the callback is presumably meant to fill `item_internal`, and `result` is set before the compare calls. So reading these fields is not a definite bug, and the finding is doubtful or a false positive. Reporting it as a warning instead of an error is more accurate."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/y/ycmd/ycmd_0+20240823+git8b61f19+ds.orig.tar.xz",
    "main ycmd-0+20240823+git8b61f19/cpp/ycm/ClangCompleter/ClangHelpers.cpp:255:12: error: Uninitialized variable: diagnostic.kind_ [uninitvar]\n     ycmd-0+20240823+git8b61f19/cpp/ycm/ClangCompleter/ClangHelpers.cpp:254:8: note: Assuming condition is true\n     ycmd-0+20240823+git8b61f19/cpp/ycm/ClangCompleter/ClangHelpers.cpp:255:12: note: Uninitialized variable: diagnostic.kind_"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "medium",
    "explanation": "`BuildDiagnostic` returns a default-constructed `Diagnostic` early when `!diagnostic_wrap`; `kind_` is assigned only after that check. The finding is still reported at the same location with the same message and the same \"Assuming condition is true\" path. The only change is severity, from error to warning. Because the uninitialized value is reached only on the path where the condition is true, it is a conditional value. Cppcheck normally reports such path-dependent findings as warnings, not errors, so the lower severity fits the finding better. Whether returning the struct with an unset enum member is a real bug depends on how callers use `kind_`, which makes a definite error label overstated either way."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/y/ycmd/ycmd_0+20240823+git8b61f19+ds.orig.tar.xz",
    "your ycmd-0+20240823+git8b61f19/cpp/ycm/ClangCompleter/ClangHelpers.cpp:255:12: warning: Uninitialized variable: diagnostic.kind_ [uninitvar]\n     ycmd-0+20240823+git8b61f19/cpp/ycm/ClangCompleter/ClangHelpers.cpp:254:8: note: Assuming condition is true\n     ycmd-0+20240823+git8b61f19/cpp/ycm/ClangCompleter/ClangHelpers.cpp:255:12: note: Uninitialized variable: diagnostic.kind_"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "low",
    "explanation": "`Diagnostic diagnostic;` is default-initialized. If `kind_` has no default member initializer (it is not set here before the early return), then returning `diagnostic` when `!diagnostic_wrap` copies an indeterminate `kind_`. The warning itself is unchanged; only its severity drops from error to warning. The error path rests on 'Assuming condition is true', so the bug only occurs on one branch. Cppcheck normally uses warning rather than error for condition-dependent findings, so the new severity fits the evidence better. The finding stays reported, so nothing is lost for users. Confidence is low because the `Diagnostic` definition is not shown."
   }
  }
 ],
 "started": "2026-10-26 23:35:34 UTC",
 "runner": "pc"
}