Re: Static analysis for "use-after-move"?

[Jim Blandy]

On Thu, Apr 28, 2016 at 8:22 PM,  wrote:

> Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道：
> > I don't really think it's a good example. TakeMediaIfKnown is accepting a
> > UniquePtr as an inout parameter: it uses, and may modify, its
> > value. It should take UniquePtr &.
> IIUC, UniquePtr can't be an inout parameter for its unique semantics
> which owns sole ownership of an object. The caller won't be able to use the
> object in a meaningful way after the function returns.
>
>
>
I'm not sure I understand. Maybe it would help if we had a more concrete
example to talk about:

$ cat unique-inout.cc
#include 
#include "mozilla/UniquePtr.h"

using mozilla::UniquePtr;

struct MediaFile {
  const char *name;
  MediaFile(const char *name) : name(name) { printf("constructing %s\n",
name); }
  ~MediaFile() { printf("destructing %s\n", name); }
};

int foo(UniquePtr , bool pleaseSwap)
{
  if (pleaseSwap) {
UniquePtr ptr = Move(arg);
arg = UniquePtr(new MediaFile("foo's"));
  }
}

int main(int argc, char **argv) {
  UniquePtr first(new MediaFile("first"));
  printf("before first call\n");
  foo(first, false);
  printf("after first call\n");

  UniquePtr second(new MediaFile("second"));
  printf("before second call\n");
  foo(second, true);
  printf("after second call\n");

}
$ ln -sf /home/jimb/moz/dbg/mfbt mozilla
$ g++ -std=c++11 -I . unique-inout.cc -o unique-inout
$ ./unique-inout
constructing first
before first call
after first call
constructing second
before second call
constructing foo's
destructing second
after second call
destructing foo's
destructing first
$

The first MediaFile's destructor doesn't run until the end of main. The
second MediaFile's destructor runs during the second call to foo, and then
foo's MedialFile's destructor runs at the end of main.

That's what I meant by a function taking a UniquePtr as an inout parameter.
It seemed to me like the function Gerald imagined should be written as in
my code above, rather than passing Move(...) as the argument. Although the
language doesn't enforce it, I think Move should be reserved for
unconditional transfers of ownership.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Static analysis for "use-after-move"?

[jwwang]

Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道：
> I don't really think it's a good example. TakeMediaIfKnown is accepting a
> UniquePtr as an inout parameter: it uses, and may modify, its
> value. It should take UniquePtr &.
IIUC, UniquePtr can't be an inout parameter for its unique semantics which 
owns sole ownership of an object. The caller won't be able to use the object in 
a meaningful way after the function returns.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

NS_New*RunnableMethod* -> New*RunnableMethod

[Kyle Huey]

NS_NewRunnableMethod has been replaced with mozilla::NewRunnableMethod.
NS_NewRunnableMethodWithArg[s] has also been collapsed into
mozilla::NewRunnableMethod.  It also now returns an already_AddRefed.

The Chromium versions of these methods have been removed.

NS_NewRunnableFunction still survives, but at some point it will be changed
too.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: IIRFilterNode

[Karl Tomlinson]

Thanks for the replies, Dan and Roy.

A first order filter node with AudioParam inputs seems a likely
future addition AFAIK.

Even with that though, having a way to apply a custom biquad
without needing to decompose into multiple textbook filters is
useful I think.  And I agree that implementing this with
AudioParams seems unnecessary and risky wrt stability.

So I think the IIRFilterNode will still be useful as a basic
building block for authors (and that is the kind of node that Web
Audio should be providing).

The discussion re extending BiquadFilterNode for this has passed
but there is an elegance in the generality of IIRFilterNode.

Daniel Minor writes:

> In this case, my plan
> was to import the blink IIRFilter as utility code as we've done in the
> past, so I don't think supporting the IIRFilterNode will cost us much time
> or effort and keeps us compatible with the spec.

I wanted to think this through now because, once this is shipped,
we can't take it back, so the cost is ongoing.

When Gecko has used Blink or Webkit's implementation in the past,
the WG has sometimes used this to argue that quirks in multiple
existing implementations should be maintained even if not
desirable.

Sometimes we just live with the quirks.  Other times the nodes
have been deprecated and replaced, but we still need to continue
to support the old nodes for backward compatibility.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Speech synthesis API

[Eitan Isaacson]

Hello,

In Firefox 49 I intend to turn on the speech synthesis API on by default in
desktop.

For those paying close attention, this is not the first mail like this.
Last time I turned it on in Nightly only to allow some fuzz testing. As of
this writing there is one blocker we are tracking. All the details can be
seen in bug 1268633.

Blink and Webkit both support synth in their stable releases.

Cheers,
 Eitan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jeff Walden]

On 04/28/2016 10:00 AM, Jonathan Kew wrote:
> Thoughts?

Another option is to ship a WinXP-specific Firefox build that doesn't provide 
ICU and ECMAScript's Intl functionality.

This would break anyone's expectation that any version of Firefox past the 
mid-30s somewhere has Intl available in it.  I don't know if anyone makes such 
expectations rather than feature-detecting.

Also this would make the story http://caniuse.com/ and similar sites try to 
tell have an asterisk by it, or something rather ugly.  Given it's WinXP only 
(and Firefox for Android's recalcitrance ;-) may potentially be broken out into 
its own column by such sites), it seems to me that particular tradeoff is a bad 
one versus claiming full support everywhere.

But it's another option, and arguably the least work that lets us improve our 
internationalization support at the same rate ICU improves.

Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jeff Muizelaar]

On Thu, Apr 28, 2016 at 1:39 PM, Jonathan Kew  wrote:

> On 28/4/16 18:11, Jeff Muizelaar wrote:
>
>> Do we use any of the OS specific parts of ICU?
>>
>
> I don't know.
>
> But even if we don't, I suspect that once they drop support for XP / 10.6,
> it won't be long before the project as a whole becomes increasingly
> difficult to build for those targets, as it'll start assuming support for
> compiler and/or runtime library features that aren't readily available
> there.
>

True, but ICU project but more willing to compromise on things like that
compared to the OS functionality mentioned below.

-Jeff

On Thu, Apr 28, 2016 at 1:00 PM, Jonathan Kew > > wrote:
>>
>> We make considerable (and growing) use of ICU for various aspects of
>> i18n support in Gecko.†
>>
>> The ICU project is proposing to drop support for Windows XP and OS X
>> 10.6 in version 58; I guess this will be released sometime shortly
>> after Unicode 9.0, which is due to appear in June.
>>
>> Markus (in the message forwarded below) mentions October 2016; I
>> assume that's when they expect to end support for ICU 57.
>>
>> So we need to decide how we're going to respond to this. Some
>> options for consideration:
>>
>> (a) Adopt ICU 58 when released, and drop Gecko support for WinXP and
>> OSX 10.6.
>>
>> (b) Keep Gecko on ICU 57 and Unicode 8.0 until  when? AFAIK, we
>> have not made any firm decisions regarding EOL for Firefox on these
>> platforms.
>>
>> (c) Keep Gecko on ICU 57 code, but update its data files to support
>> Unicode 9.0. This would take some effort on our side, though
>> _probably_ not very much.
>>
>> (d) Push back against the ICU proposal to drop these platforms, and
>> see if we can convince them to delay it. (No guarantees, though at
>> least they're asking. If we had a specific end date to propose, I'd
>> guess that might help our case.)
>>
>> In the case of either (b) or (c), we'd also need to take
>> responsibility for handling any critical security issues that are
>> discovered that affect the no-longer-maintained version we'd be
>> shipping (e.g. by backporting fixes from the latest upstream version).
>>
>>
>> Thoughts?
>>
>> JK
>>
>>
>> † Except on Android, where we maintain separate code to support some
>> features; others are simply missing.
>>
>>
>>  Forwarded Message 
>> Subject:Re: [icu-design] [icu-support] Drop Windows XP and
>> OSX 10.6
>> support
>> Date:   Thu, 28 Apr 2016 08:55:55 -0700
>> From:   Markus Scherer > >
>> To: icu-design > >
>> CC: ICU support mailing list > >,
>> Jonathan Kew > >>
>>
>>
>>
>> On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis > 
>> >> wrote:
>>
>>  Jonathan and other users,
>>Please comment on whether dropping Windows XP for ICU 58 will
>>  cause significant problems.
>>We discussed this for 57 (as per below) but no code changes
>> were made.
>>
>>
>> For ICU 57, we were just thinking of removing some Windows XP-specific
>>synchronization code. We decided to just keep that for 57.
>>
>> For ICU 58, we are looking at switching more code over to Windows
>> Vista/7/8 APIs because Windows XP and Windows Server 2003 only support
>> i18n APIs with LCID parameters and cannot support some languages at
>> all.
>> Newer Windows versions added APIs that take language tag strings. This
>> is important for an i18n library on a major platform...
>>
>> For how long do you plan to support Windows XP past October 2016?
>> Could
>> you stay on ICU 57/CLDR 29/Unicode 8 until you stop supporting
>> Windows XP?
>>
>> Also, Windows Vista seems to have very low market share and seems to
>> be
>> getting dropped by vendors around the same time they drop XP.
>> Is it ok to skip Vista and set Windows 7 as the new base for ICU 58?
>>
>> Best regards,
>> markus
>>
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org > >
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jonathan Kew]

On 28/4/16 18:11, Jeff Muizelaar wrote:

Do we use any of the OS specific parts of ICU?


I don't know.

But even if we don't, I suspect that once they drop support for XP / 
10.6, it won't be long before the project as a whole becomes 
increasingly difficult to build for those targets, as it'll start 
assuming support for compiler and/or runtime library features that 
aren't readily available there.


JK




-Jeff

On Thu, Apr 28, 2016 at 1:00 PM, Jonathan Kew > wrote:

We make considerable (and growing) use of ICU for various aspects of
i18n support in Gecko.†

The ICU project is proposing to drop support for Windows XP and OS X
10.6 in version 58; I guess this will be released sometime shortly
after Unicode 9.0, which is due to appear in June.

Markus (in the message forwarded below) mentions October 2016; I
assume that's when they expect to end support for ICU 57.

So we need to decide how we're going to respond to this. Some
options for consideration:

(a) Adopt ICU 58 when released, and drop Gecko support for WinXP and
OSX 10.6.

(b) Keep Gecko on ICU 57 and Unicode 8.0 until  when? AFAIK, we
have not made any firm decisions regarding EOL for Firefox on these
platforms.

(c) Keep Gecko on ICU 57 code, but update its data files to support
Unicode 9.0. This would take some effort on our side, though
_probably_ not very much.

(d) Push back against the ICU proposal to drop these platforms, and
see if we can convince them to delay it. (No guarantees, though at
least they're asking. If we had a specific end date to propose, I'd
guess that might help our case.)

In the case of either (b) or (c), we'd also need to take
responsibility for handling any critical security issues that are
discovered that affect the no-longer-maintained version we'd be
shipping (e.g. by backporting fixes from the latest upstream version).


Thoughts?

JK


† Except on Android, where we maintain separate code to support some
features; others are simply missing.


 Forwarded Message 
Subject:Re: [icu-design] [icu-support] Drop Windows XP and
OSX 10.6
support
Date:   Thu, 28 Apr 2016 08:55:55 -0700
From:   Markus Scherer >
To: icu-design >
CC: ICU support mailing list >,
Jonathan Kew >



On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis 
>> wrote:

 Jonathan and other users,
   Please comment on whether dropping Windows XP for ICU 58 will
 cause significant problems.
   We discussed this for 57 (as per below) but no code changes
were made.


For ICU 57, we were just thinking of removing some Windows XP-specific
   synchronization code. We decided to just keep that for 57.

For ICU 58, we are looking at switching more code over to Windows
Vista/7/8 APIs because Windows XP and Windows Server 2003 only support
i18n APIs with LCID parameters and cannot support some languages at all.
Newer Windows versions added APIs that take language tag strings. This
is important for an i18n library on a major platform...

For how long do you plan to support Windows XP past October 2016? Could
you stay on ICU 57/CLDR 29/Unicode 8 until you stop supporting
Windows XP?

Also, Windows Vista seems to have very low market share and seems to be
getting dropped by vendors around the same time they drop XP.
Is it ok to skip Vista and set Windows 7 as the new base for ICU 58?

Best regards,
markus


___
dev-platform mailing list
dev-platform@lists.mozilla.org 
https://lists.mozilla.org/listinfo/dev-platform




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jeff Muizelaar]

Do we use any of the OS specific parts of ICU?

-Jeff

On Thu, Apr 28, 2016 at 1:00 PM, Jonathan Kew  wrote:

> We make considerable (and growing) use of ICU for various aspects of i18n
> support in Gecko.†
>
> The ICU project is proposing to drop support for Windows XP and OS X 10.6
> in version 58; I guess this will be released sometime shortly after Unicode
> 9.0, which is due to appear in June.
>
> Markus (in the message forwarded below) mentions October 2016; I assume
> that's when they expect to end support for ICU 57.
>
> So we need to decide how we're going to respond to this. Some options for
> consideration:
>
> (a) Adopt ICU 58 when released, and drop Gecko support for WinXP and OSX
> 10.6.
>
> (b) Keep Gecko on ICU 57 and Unicode 8.0 until  when? AFAIK, we have
> not made any firm decisions regarding EOL for Firefox on these platforms.
>
> (c) Keep Gecko on ICU 57 code, but update its data files to support
> Unicode 9.0. This would take some effort on our side, though _probably_ not
> very much.
>
> (d) Push back against the ICU proposal to drop these platforms, and see if
> we can convince them to delay it. (No guarantees, though at least they're
> asking. If we had a specific end date to propose, I'd guess that might help
> our case.)
>
> In the case of either (b) or (c), we'd also need to take responsibility
> for handling any critical security issues that are discovered that affect
> the no-longer-maintained version we'd be shipping (e.g. by backporting
> fixes from the latest upstream version).
>
>
> Thoughts?
>
> JK
>
>
> † Except on Android, where we maintain separate code to support some
> features; others are simply missing.
>
>
>  Forwarded Message 
> Subject:Re: [icu-design] [icu-support] Drop Windows XP and OSX 10.6
> support
> Date:   Thu, 28 Apr 2016 08:55:55 -0700
> From:   Markus Scherer 
> To: icu-design 
> CC: ICU support mailing list ,
> Jonathan Kew 
>
>
>
> On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis  > wrote:
>
> Jonathan and other users,
>   Please comment on whether dropping Windows XP for ICU 58 will
> cause significant problems.
>   We discussed this for 57 (as per below) but no code changes were
> made.
>
>
> For ICU 57, we were just thinking of removing some Windows XP-specific
>   synchronization code. We decided to just keep that for 57.
>
> For ICU 58, we are looking at switching more code over to Windows
> Vista/7/8 APIs because Windows XP and Windows Server 2003 only support
> i18n APIs with LCID parameters and cannot support some languages at all.
> Newer Windows versions added APIs that take language tag strings. This
> is important for an i18n library on a major platform...
>
> For how long do you plan to support Windows XP past October 2016? Could
> you stay on ICU 57/CLDR 29/Unicode 8 until you stop supporting Windows XP?
>
> Also, Windows Vista seems to have very low market share and seems to be
> getting dropped by vendors around the same time they drop XP.
> Is it ok to skip Vista and set Windows 7 as the new base for ICU 58?
>
> Best regards,
> markus
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

ICU proposing to drop support for WinXP (and OS X 10.6)

[Jonathan Kew]

We make considerable (and growing) use of ICU for various aspects of 
i18n support in Gecko.†


The ICU project is proposing to drop support for Windows XP and OS X 
10.6 in version 58; I guess this will be released sometime shortly after 
Unicode 9.0, which is due to appear in June.


Markus (in the message forwarded below) mentions October 2016; I assume 
that's when they expect to end support for ICU 57.


So we need to decide how we're going to respond to this. Some options 
for consideration:


(a) Adopt ICU 58 when released, and drop Gecko support for WinXP and OSX 
10.6.


(b) Keep Gecko on ICU 57 and Unicode 8.0 until  when? AFAIK, we have 
not made any firm decisions regarding EOL for Firefox on these platforms.


(c) Keep Gecko on ICU 57 code, but update its data files to support 
Unicode 9.0. This would take some effort on our side, though _probably_ 
not very much.


(d) Push back against the ICU proposal to drop these platforms, and see 
if we can convince them to delay it. (No guarantees, though at least 
they're asking. If we had a specific end date to propose, I'd guess that 
might help our case.)


In the case of either (b) or (c), we'd also need to take responsibility 
for handling any critical security issues that are discovered that 
affect the no-longer-maintained version we'd be shipping (e.g. by 
backporting fixes from the latest upstream version).



Thoughts?

JK


† Except on Android, where we maintain separate code to support some 
features; others are simply missing.



 Forwarded Message 
Subject:Re: [icu-design] [icu-support] Drop Windows XP and OSX 10.6
support
Date:   Thu, 28 Apr 2016 08:55:55 -0700
From:   Markus Scherer 
To: icu-design 
CC: ICU support mailing list ,
Jonathan Kew 



On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis > wrote:

Jonathan and other users,
  Please comment on whether dropping Windows XP for ICU 58 will
cause significant problems.
  We discussed this for 57 (as per below) but no code changes were 
made.



For ICU 57, we were just thinking of removing some Windows XP-specific
  synchronization code. We decided to just keep that for 57.

For ICU 58, we are looking at switching more code over to Windows
Vista/7/8 APIs because Windows XP and Windows Server 2003 only support
i18n APIs with LCID parameters and cannot support some languages at all.
Newer Windows versions added APIs that take language tag strings. This
is important for an i18n library on a major platform...

For how long do you plan to support Windows XP past October 2016? Could
you stay on ICU 57/CLDR 29/Unicode 8 until you stop supporting Windows XP?

Also, Windows Vista seems to have very low market share and seems to be
getting dropped by vendors around the same time they drop XP.
Is it ok to skip Vista and set Windows 7 as the new base for ICU 58?

Best regards,
markus


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: IIRFilterNode

[Daniel Minor]

On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson  wrote:

> Daniel Minor writes:
>
> > Summary: This provides an alternative to using BiquadFilterNode when
> > odd-order filters are required or automation is not needed. It is part of
> > the Web Audio spec and is already implemented in Blink.
>
> Thanks for looking at this, Daniel.
>
>
Thanks for your comments Karl!

To be honest, I'm not sure how useful IIRFilterNodes will be in practice.
One could argue that we should see how widely the blink implementation is
used "in the wild" before we implement it ourselves.In this case, my plan
was to import the blink IIRFilter as utility code as we've done in the
past, so I don't think supporting the IIRFilterNode will cost us much time
or effort and keeps us compatible with the spec.



> I fear that high order filters are going to have problems due to numerical
> round-off, as pointed out in
> https://github.com/WebAudio/web-audio-api/issues/323#issuecomment-60545047
>
> Do you know whether that is going to be a general problem or whether many
> high order filters will be OK in practice?
>
>
We're using doubles rather than floats, but I'm not sure if this is
sufficient to avoid numerical problems with higher order filters.


> There is some discussion here but my understanding is limited:
> http://signal.ece.utexas.edu/~arslan/courses/dsp/lecture25.ppt
>
> There was some tinkering of test output precision for up to 4th order
> filters
> in patch sets 7, 8, 9, and 19 of
> https://codereview.chromium.org/1361233004/
>
> The Blink implementation doesn't factor into low-order filters, and I
> expect
> it would be quite some work to do this.
>
> I wonder whether it may be that the IIRFilterNode should be used only for
> first and second order filters and higher order filters should be composed
> as
> a series of these?
>
> IIRFilterNode is probably an OK solution for first-order and custom biquad
> filters, as long as we don't then need a pole/zero filter node with
> AudioParam
> parameters because someone wants automation (as already requested for and
> available with BiquadFilterNode).  Then we'd have yet another filter node,
> which would be unfortunate.  Do you think this is likely?
>

The discussion in https://github.com/WebAudio/web-audio-api/issues/323
ruled this out because it seemed of limited utility and could be
challenging to implement. We should work to make sure that automation does
not sneak in.

I think it might make sense to raise your concerns as issues against the
Web Audio spec. I'm sure you'll get more informed feedback than I can
provide :)

Dan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Armen Zambrano G.]

On 2016-04-26 05:54 PM, Mike Hommey wrote:

On Tue, Apr 26, 2016 at 03:49:11PM +0200, Gabor Krizsanits wrote:

As someone who was high on the list of try server usage for two
weeks  My problem was a test I tried to fix for both e10s and
non-e10s, and it timed out _sometimes_ on _some_ platforms even
depending on debug/release build. It was a whack-a-mole game by
fiddling with the test and a complex patch. I did stop old builds but
I did not run only the test in question but the rest of them as well
because of the invasive nature of the patch the whole thing was
sitting on. Probably I could have been smarter, BUT...

What would have helped me a lot in this case and most cases when I
rely on the try server is the ability to push a new changeset on top
of my previous one, and tell the server to use the previous session
instead of a full rebuild (if there is only a change in the tests
that's even better, no rebuild at all) and then tell the server
exactly which tests I want to re-run with those changes (as it can be
an empty set this can be used to trigger additional tests for a
previous push). This could all be done by an extensions to the try
syntax like -continue [hash]. As an addition this follow up push would
also kill the previous job.

Maybe there is already such functionality available, just I'm not
aware of it (I would be so happy if this were the case, and would feel
bad for the machine hours I wasted...), if so please let me know.


You can do that more or less with moz-ci. IIRC, the setup is detailed
somewhere on Armen's blog (CCed, he might be able to point you there)

Mike



It is possible for Buildbot jobs (not TaskCluster) with a python script, 
you need to specify where to find the builds and test bundles are [1]


However, this is not optimal as it is.
You need to upload the new test bundle somewhere and point to that.

I've filed this as https://bugzilla.mozilla.org/show_bug.cgi?id=1268481
and tracking it under making try awesome meta bug.


[1] 
https://github.com/mozilla/mozilla_ci_tools/blob/master/scripts/trigger.py#L87


--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Static analysis for "use-after-move"?

[Karl Tomlinson]

Xidorn Quan writes:

> I think this specific case should actually use UniquePtr& rather
> than && in parameter for conditional move, so that callsite can only pass
> in an lvalue, and we don't need a Move there.

Jim Blandy writes:

> TakeMediaIfKnown is accepting a
> UniquePtr as an inout parameter: it uses, and may modify, its
> value. It should take UniquePtr &.
>
> UniquePtr.h disagrees with me:
>
>  * ...  To conditionally transfer
>  * ownership of a resource into a method, should the method want it, use a
>  * |UniquePtr&&| argument.

UniquePtr* would make it clear at the call site that
something out of the ordinary can happen.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform