<html>
<head>
<base href="https://bugs.llvm.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 - Mismatched Clang lock annotations (between prototype and impl) can lead to false negatives"
href="https://bugs.llvm.org/show_bug.cgi?id=42849">42849</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Mismatched Clang lock annotations (between prototype and impl) can lead to false negatives
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Frontend
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>leonardchan@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=22326" name="attach_22326" title="reproducer">attachment 22326</a> <a href="attachment.cgi?id=22326&action=edit" title="reproducer">[details]</a></span>
reproducer
Filing for a coworker
--------------------------
As the title says, a mismatch between lock annotations for a function/method
prototype and for the function's implementation can lead to false negatives for
the static thread analysis feature in clang.
I'll let the example do the talking. Here is a godbolt link which shows the
behavior. <a href="https://godbolt.org/z/2rCs3U">https://godbolt.org/z/2rCs3U</a>
The code is also explicitly attached to this bug for safe-keeping (I'm not sure
how long godbolt links are active for). The summary of the issues are as
follows.
1. If you prototype a function and provide no annotations, then you use the
function with some requirement, and finally you implement the function with an
annotation which conflicts with the usage requirement; clang will accept this
when it should not.
2. Same as #1, but this time you prototype the function with a compatible
annotation, then you implement the function with a conflicting annotation.
3. Similar to #2, but this time you don't even need to bother to use the
function. Just prototype it twice with conflicting annotations.
This happens for methods in C++ as well (except for #3, as C++ does not all you
to re-declare methods with identical signatures in the first place, regardless
of what annotations are)
IMO, all of these should be compile time failures. Specifically, I think the
behavior should be as follows.
1. For a given prototype of a function, all subsequent prototypes should be
required to have identical annotations. This is not to say that they have to
match character for character, just that if a prototype says that it requires
lock instance X, and excludes lock instance Y, then all other prototypes
encountered during compilation must agree with the first prototype encountered.
This includes the no-annotation state. If the first prototype encountered
says no annotations, then all subsequent prototypes must agree.
2. Implementations must follow rule #1 as well, with the following exception.
If an implementation has no annotations, but a prototype has one or more
annotations, the implementation is assumed to have the same annotations as the
prototype. This is mostly a convenience feature as the vast majority of code I
have encountered which uses these thread safety annotations uses C++, and is
annotated at the prototype of the methods (and not annotated at all when you
hit implementation).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>