Gregory Szorc <mailto:g...@mozilla.com>
April 10, 2015 at 9:43 PM
On Fri, Apr 10, 2015 at 11:46 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
Why do we merely update the style guide? We have a custom Clang compiler
plugin. I think we should have the Clang compiler plugin enforce our style
guidelines by refusing to compile code that is against policy. This would
enable reviewers to stop focusing on policing the style guide and enable
them to focus more on the correctness of code. This will result in faster
reviews and/or higher quality code.
We already do some of this with the existing Clang compiler plugin. But
it's far from comprehensive. I think we should strive for a world where
machines, not humans, are enforcing the style guide.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Ehsan Akhgari <mailto:ehsan.akhg...@gmail.com>
April 10, 2015 at 11:46 AM
I would like to propose that we should ban the usage of refcounted objects
inside lambdas in Gecko. Here is the reason:
Consider the following code:
nsINode* myNode;
TakeLambda([&]() {
myNode->Foo();
});
There is nothing that guarantees that the lambda passed to TakeLambda is
executed before myNode is destroyed somehow. While it's possible to verify
on a case by case basis that this code is indeed safe, I think it's too
error prone to keep these invariants over time. Given the fact that if
things go wrong we'd deal with a UAF bug which will be sec-critical, I
think it's better to be safe than sorry here.
If nobody objects, I'll update the style guide in the next few days. If
you do object, please make a case for why the above analysis is incorrect
and why the usage of refcounted objects in lambdas in general is safe.
Cheers,
------------------------------------------------------------------------
Ideally, this sounds like a great idea to me (says the tech writer who
isn't having to deal with this stuff directly in any significant way).
My concern would be impact on project timelines. Is this something that
would bust so many existing allocations/deallocations that things would
take weeks to bring up to snuff? What are the odds that in the process
of fixing these refcounted objects, new (and potentially insidiously
hard to spot) bugs are introduced?
Would it be possible to enforce this rule gradually, over time, by
enforcing it one or two modules (or other code areas) at a time?
--
Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
