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

David Blaikie dblaikie at gmail.com
Mon Oct 6 13:39:56 PDT 2014


Clang already has some infrastructure to try warn for this - the "consumed"
analysis is a broad analysis designed to be used with type attributes to
indicate which operations are valid in which states of an object. Some
default behavior for moved-from objects might be helpful, but I'm not sure.

if the object you're dealing with only became moved-from in one condition,
but was returned unconditionally:

  T t = init();
  if (x)
    func(std::move(t));
  ...
  return t;

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).

On Mon, Oct 6, 2014 at 1:26 PM, Seth Fowler <mark.seth.fowler at gmail.com>
wrote:

> Hi all,
>
> I recently got bitten by a bug that was caused by using a value (more
> specifically, returning it from a function) after moving it. Since this
> move happened only within one rarely executed conditional branch of a
> fairly large function, it wasn’t visually obvious why the behavior was
> different from what I expected, and it took me some time to track the issue
> down.
>
> Obviously using a value after moving from it is legal C++, but in my own
> experience with using std::move, code like this almost always indicates a
> bug, or at least bad style. I’m curious whether others feel the same way.
> If use-after-move is only rarely useful, it would be nice to print a
> warning when it happens, perhaps with a way to disable the warning by using
> more explicit syntax (similar to how the warning for assignment in an ‘if’
> conditional expression works).
>
> If there was a patch to implement this, would there be support for
> including it in clang?
>
> Thanks,
> - Seth
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141006/63542141/attachment.html>


More information about the cfe-dev mailing list