[cfe-dev] Use-after-move warning?

[Delesley Hutchins]

The consumed analysis tracks three states: "consumed", "unconsumed", and
"unknown".  If an object is only consumed on one branch, then it would wind
up in the "unknown" state afterward.

You can specify which operations are permitted in which states.  For a
strict analysis, you can say "warn whenever a unique_ptr is dereferenced in
any state other than unconsumed."  A less strict version might say "only
warn on dereference if it's in the consumed state."  The less strict
version will have a higher false negative rate, but a much lower false
positive rate, especially for a widely-used type like unique_ptr.

That's where things get tricky, because the C++ standard says that
std::move must leave the object in a valid state.  Some people rely on that
behavior in their code, and routinely use null unique_ptrs, whereas some
other people don't.  So for a widely-used type, it's difficult to come up
with a set of annotations that works for everyone.  It's much easier if
you're willing to create a strict_unique_ptr class (or something similar),
that absolutely does not allow use-after-move.

BTW, the consumed analysis works, but hasn't been widely deployed, due to
the false positives issue.  Expect to see some bugs.

  -DeLesley


On Tue, Oct 7, 2014 at 8:19 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, Oct 7, 2014 at 1:00 AM, David Chisnall <
> David.Chisnall at cl.cam.ac.uk> wrote:
>
>> On 6 Oct 2014, at 21:39, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> > I doubt it's reliable enough to warn on that generally - the user
>> might've wanted to return an empty value in that situation. (think of the
>> case where T is std::unique_ptr, with a well defined move-from state that
>> users might rely on).
>>
>> I think that the number of times that I've used that pattern is a tiny
>> handful of the times where I've used std::move, so perhaps an attribute to
>> flag that 'yes, I really meant to return this value even though it's now
>> empty' is the way forward?
>>
>
> Perhaps - I'm just suggesting some of the gotchas I'd want to keep an eye
> out for when evaluating the quality of such a warning. Numbers trump
> everything - if someone implements it, surveys a large codebase, and finds
> few enough false positives (with reasonable ways to rewrite them to not
> trigger the warning) - that's success.
>
>
>>
>> David
>>
>>
>


-- 
DeLesley Hutchins | Software Engineer | delesley at google.com | 505-206-0315
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141007/cffa125a/attachment.html>