Comments on: nsresult analysis

By: Noel Grandin

Noel Grandin — Wed, 01 Apr 2009 09:18:02 +0000

One way to build the lattice would be to initially define all typedefs as being incompatible, and then slowly adding permitted rules until a decent ruleset has been built.
i.e. “not allowed unless permitted”.

That would also make catching new problems at lot easier, because they’d immediately show up when new typedefs were added.

But as Joshua noted, this would need an awful lot of cleanup work to be really effective.
But that cleanup work would probably be worthwhile in it’s own right, even if rather tedious.

By: Jeff Walden

Jeff Walden — Wed, 01 Apr 2009 04:54:26 +0000

Layout hackers might note the common-typing of so-called appunits and CSS pixels, which are currently the same integer type and which at times have been used without conversions one way or the other. Note also that these units may eventually be changed to floats (to get auto-saturating behavior when over- and underflows occur), so you’d have to be prepared for that possibility.

By: Joshua Cranmer

Joshua Cranmer — Wed, 01 Apr 2009 01:36:15 +0000

One of the crufty old files I’ve had to deal with loves to mix PRInt32 and nsresult together.

Another thing that would be cool–if difficult–would be to have C++ analysis that could warn if you passing something bad to a pseudo-enum for IDL code, like:
mailnews’s nsMsgSearchCore values.

By: Shawn Wilsher

Shawn Wilsher — Tue, 31 Mar 2009 23:46:18 +0000

I know I’ve caught myself using NS_ENSURE_SUCCESS, and returning a PRBool for an nsresult before. Wasn’t caught in review either, but I caught it before checkin.