<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Split "assert (a && b)" statements into "assert(a); assert(b)", for more precise diagnostics"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110678">110678</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Split "assert (a && b)" statements into "assert(a); assert(b)", for more precise diagnostics
</td>
</tr>
<tr>
<th>Product</th>
<td>xorg
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Keywords</th>
<td>patch
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>low
</td>
</tr>
<tr>
<th>Component</th>
<td>Driver/intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>chris@chris-wilson.co.uk
</td>
</tr>
<tr>
<th>Reporter</th>
<td>adam_richter2004@yahoo.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>adam_richter2004@yahoo.com
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=144271" name="attach_144271" title="Patch to split assert(a && b) statements into assert(a) and assert(b) in git version of xf86-video-intel">attachment 144271</a> <a href="attachment.cgi?id=144271&action=edit" title="Patch to split assert(a && b) statements into assert(a) and assert(b) in git version of xf86-video-intel">[details]</a></span> <a href='page.cgi?id=splinter.html&bug=110678&attachment=144271'>[review]</a>
Patch to split assert(a && b) statements into assert(a) and assert(b) in git
version of xf86-video-intel
Many thanks to Adam Jackson via Maarten Maathuis for redirecting me to submit
this patch here.
This patch separates each statement of the form assert(a && b) into "assert(a)"
and "assert(b)" statements.
If you will excuse the boilerplate language, here are some arguments in favor
of this practice. Thanks for considering this patch.
1. Assertion failures are often sporadic, and users who report them may
not be in a position to efficiently narrow them down further, so it
is important to get as much precision from each assertion failure as
possible.
2. It is a more efficient use of developers time when a bug report
arrives if the problem has been narrowed down that much more. A
new bug report may initially attract more interest, so, if the
problem has been narrowed down that much more, it may increase the
chance that developers may invest the time to try to resolve the
problem, and also reduce unnecessary traffic on the developer mailing
list about possible causes of the bug that separating the assertion
was able to rule out.
3. When using a debugger to step over an assertion failure in the
first part of the statement, the second part is still tested.
4. Providing separate likelihood hints to the compiler in the form
of separate assert statements does not require the compiler to
be quite as smart to recognize that it should optimize both branches,
although I do not know if that makes a difference for any compiler
commonly used to compile X (that is, I suspect that they are all
smart enough to realize is that "a && b" is likely true, then "a"
is likely true and "b" is likely true).
5. In my humble opinion, separated assertions are almost always more
readable, sometimes eliminating parentheses, often making
references to the same values line up on the same columns, which
can make range checks more obvious, and sometimes changing
multi-line conditions to separate single line conditions, which can
be recognized separately.
Consider, for example, how columnization in this makes this range
check more recongizable and makes it easier to recognize in a glance
that it is a bounds check and what the bounds are:
assert(reg.vstride >= 0 && reg.vstride <
ARRAY_SIZE(vstride_for_reg));
... vs. ...
assert(reg.vstride >= 0);
assert(reg.vstride < ARRAY_SIZE(vstride_for_reg));
A possible counter-argument to this might be that, in a sequence of
assertions, can be informative to group related assertions together,
which I think is true, but it is possible to get this other means, such
as by using blank lines to separate express such grouping.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>