D28478: [FileProtocol] change statx stat_dev() to return makedev(major, minor)

Ahmad Samir noreply at phabricator.kde.org
Sat Apr 11 10:16:53 BST 2020


ahmadsamir added a comment.


  In D28478#645682 <https://phabricator.kde.org/D28478#645682>, @dfaure wrote:
  
  > In D28478#645019 <https://phabricator.kde.org/D28478#645019>, @ahmadsamir wrote:
  >
  > > hmm... first this is a copy-paste "error" on my part, I personally never use & when the RHS is a temporary (I don't see the point).
  >
  >
  > The point is to avoid a copy ;-)
  >
  > If the RHS is a value, this extends its lifetime.
  >  But if it's a reference itself, then indeed we depend on its lifetime....
  >
  > >   the job may finish and get deleted by the time we call entry.numberValue() on line 1534.
  >
  > That's not a "guess", it's confirmed by what ASAN tells us in its second backtrace.
  >
  > > And maybe statResult() shouldn't return a reference (or a const reference for that matter, because if the caller uses 'entry = job->statResult()'
  > >  then statResult() returning a const & doesn't make any difference if it's copied...).
  >
  > Well you get two copies then, one at "return" and one at '=' (technically that's an assignment, unless entry is actually declared on the same line).
  
  
  I meant something like:
  const int i = foo();
  the return from foo() is copied into i and then it's gone.
  const int &i = foo();
  the return from foo() will be stored in a temporary, and it will stay around until i goes out of scope. So, there's only one "copy" of the return from foo() around, I'd rather take the one stored in i (https://herbsutter.com/2013/05/13/gotw-2-solution-temporary-objects/); I know that's nitpicking, but anyway. So mainly when it's an initialisation rather than assignment. :)
  
  > Anyhow the fix is clear, remove the & :-)
  
  OK, will do.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D28478

To: ahmadsamir, #frameworks, dfaure, meven, bruns
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200411/6c69cb91/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list