Is ReentrantMonitorAutoExit a footgun?

[jwwang]

I just came to realize:

ReentrantMonitorAutoEnter lock1(...);
ReentrantMonitorAutoEnter lock2(...);
{
  ReentrantMonitorAutoExit unlock1(...);
  // This will not release the monitor.
  {
ReentrantMonitorAutoExit unlock2(...);
// This will release the monitor.
  }
}

Sometimes it is not clear how many ReentrantMonitorAutoExits are required to 
effectively release the monitor.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Are char* and uint8_t* interchangeable?

[jwwang]

Is it always safe and portable to do:

char* p1 = ...;
uint8_t* p2 = reinterpret_cast(p1);
uint8_t u8 = p2[0];

without breaking strict aliasing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Be more lenient with the NS_LITERAL_CSTRING macro

[jwwang]

We have NS_NAMED_LITERAL_CSTRING which seems to be a better and safer 
alternative for literal strings. And we should avoid using nsLiteralCString 
directly to avoid the pitfall described by James.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Be more lenient with the NS_LITERAL_CSTRING macro

[jwwang]

For
static constexpr auto& kSomeStrLiteral = "hello world";
NS_LITERAL_CSTRING(kSomeStrLiteral) is not allowed.

However, we can have
auto s1 = nsLiteralCString("hello world");
auto s2 = nsLiteralCString(kSomeStrLiteral);

I wonder why didn't we define NS_LITERAL_CSTRING(s) as
static_cast(nsLiteralCString(s))
?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[jwwang]

Kan-Ru Chen (陳侃如)於 2016年5月24日星期二 UTC+8下午4時00分12秒寫道：
> I think the current practice is to use already_AddRefed as return
> type and return foo.forget()
> 
> Kanru

I think that is the legacy when we don't have move semantics. Returning 
RefPtr won't incur ref-counting overhead and is more expressive and 
functional.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Return-value-optimization when return type is RefPtr

[jwwang]

For

RefPtr GetFoo() {
  RefPtr foo;
  // ...
}

should we:

1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
2. return foo.forget()
3. return Move(foo)

Which one is preferred?

ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also 
true for other compilers.
___
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

The convention to pass a parameter when ownership transfer is optional

[jwwang]

https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/mfbt/UniquePtr.h#l182

"To unconditionally transfer ownership of a UniquePtr into a method, use a 
|UniquePtr| argument.  To conditionally transfer ownership of a resource into a 
method, should the method want it, use a |UniquePtr&&| argument."

Does that also apply to already_AddRefed<>&& or we stick to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1247972#c19?

Btw, we have some code like 
https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/dom/base/WebSocket.cpp#l2790
 where it really should be just already_AddRefed<> since the ownership is 
always transferred.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The convention to pass a parameter when ownership transfer is optional

[jwwang]

I am tempted to assume |t| will be an empty shell after foo(Move(t)) if I don't 
see the prototype foo(T&&).

For |bar(already_AddRefed&&)|, it is also possible for the callsite to say 
|bar(r.forget())| without forcing the caller to handle conditional ownership 
transfer which won't be caught until runtime.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform