Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.508 (Entity 5.508) Content-Type: text/plain; charset="utf-8" References: <5a3073d68c236_601632732824454@ss1435.mail> X-RT-Interface: Web Message-ID: Content-Disposition: inline In-Reply-To: X-RT-Original-Encoding: utf-8 RT-Send-CC: Content-Length: 1789 To be honest, I cannot really fathom what Coverity is complaining about here. According to the detailed Coverity Scan report, these are the "events" contributing to the first "issue": incr: Incrementing query_hooks@dim0. The value of query_hooks@dim0 is now 1. incr: Incrementing query_hooks@dim0. The value of query_hooks@dim0 is now 2. incr: Incrementing query_hooks@dim0. The value of query_hooks@dim0 is now 3. const: At condition query_hooks@dim0 < 3UL, the value of query_hooks@dim0 must be equal to 3. dead_error_condition: The condition query_hooks@dim0 < 3UL cannot be true. CID undefined (#1 of 1): Logically dead code (DEADCODE) dead_error_line: Execution cannot reach this statement: query_hooks[query_hooks@dim.... All of these "events" "happen" on the same source code line and they are identical for both "issues" found. Given the above: - I do not understand how merging rt46841 would silence these warnings. Mark, if Coverity's notes make sense to you, could you please try explaining it all to me like I am five? - Even if merging rt46841 would indeed get rid of these warnings, I still do not like how it sacrifices code clarity for silencing an obvious false alarm. Since neither NS_QUERY_HOOKS_LAST nor NS_QUERY_HOOKS_COUNT is used as a hook identifier, cannot we just keep using the latter, adding "+ 1" to the array size to achieve the same effect with minimal effort? - I am not totally opposed to adding a quick workaround for these "issues" given that "production-quality" hooks are planned for 9.13 and these would not use whole-table assignments employed in the red-flagged code anyway. But I would like to at least properly understand Coverity's reasons for complaining.