On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
On 1/6/2014 6:06 PM, smaug wrote:
On 01/07/2014 01:38 AM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep
using NULL or PRUnichar, or invent their own string
On Tuesday 2014-01-07 09:13 +0100, Ms2ger wrote:
On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
Since Benjamin's message of November 22:
news://news.mozilla.org/mailman.11861.1385151580.23840.dev-platf...@lists.mozilla.org
(search for Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS if you
2014/1/7 L. David Baron dba...@dbaron.org
On Tuesday 2014-01-07 09:13 +0100, Ms2ger wrote:
On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
Since Benjamin's message of November 22:
news://
news.mozilla.org/mailman.11861.1385151580.23840.dev-platf...@lists.mozilla.org
(search for Please
I support getting rid of NS_ENSURE_*.
Gavin
On Tue, Jan 7, 2014 at 3:13 AM, Ms2ger ms2...@gmail.com wrote:
On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
On 1/6/2014 6:06 PM, smaug wrote:
On 01/07/2014 01:38 AM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
Benoit Jacob wrote:
I would like a random voice in favor of deprecating NS_ENSURE_* for the reason
that hiding control flow behind macros is IMO one of the most evil usage
patterns of macros.
So you're saying that
nsresult rv = Foo();
NS_ENSURE_SUCCESS(rv, rv);
is hiding the control flow
2014/1/7 Neil n...@parkwaycc.co.uk
Benoit Jacob wrote:
I would like a random voice in favor of deprecating NS_ENSURE_* for the
reason that hiding control flow behind macros is IMO one of the most evil
usage patterns of macros.
So you're saying that
nsresult rv = Foo();
On 1/7/2014 12:58 PM, Benoit Jacob wrote:
I would like a random voice in favor of deprecating NS_ENSURE_* for
the reason that hiding control flow behind macros is IMO one of the
most evil usage patterns of macros.
In general, I would agree. I have no problems with killing, say,
Benoit Jacob wrote:
I'm scanning a function for possible early returns
Good thing you don't have to deal with C++ exceptions then.
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
For example, if I'm scanning a function for possible early returns (say I'm
debugging a bug where we're forgetting to close or delete a thing before
returning), I now need to scan for NS_ENSURE_SUCCESS in addition to
On 14-01-07 08:04 PM, Kyle Huey wrote:
On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
For example, if I'm scanning a function for possible early returns (say I'm
debugging a bug where we're forgetting to close or delete a thing before
returning), I now need to
2014/1/7 Kyle Huey m...@kylehuey.com
On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
For example, if I'm scanning a function for possible early returns (say
I'm
debugging a bug where we're forgetting to close or delete a thing before
returning), I now need to
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep
using NULL or PRUnichar, or invent their own string class, they will
be corrected.
Maybe. But we also have a very large number of deprecated or
effectively-deprecated constructs
On 1/6/2014, 6:38 PM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep
using NULL or PRUnichar, or invent their own string class, they will
be corrected.
Maybe. But we also have a very large number of
On 01/07/2014 01:38 AM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep using NULL or
PRUnichar, or invent their own string class, they will be corrected.
Maybe. But we also have a very large number of
On 1/6/2014 6:06 PM, smaug wrote:
On 01/07/2014 01:38 AM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep
using NULL or PRUnichar, or invent their own string class, they will
be corrected.
Maybe. But we
15 matches
Mail list logo
