Comment on attachment 8344374 [details] [diff] [review] Build modules/libpref/ in unified mode What's up with nsPrefBranch::NotifyObserver returning an nsresult-as-int? That seems weird and there's no comment explaining it.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Comment on attachment 8344374 [details] [diff] [review] > Build modules/libpref/ in unified mode > > What's up with nsPrefBranch::NotifyObserver returning an nsresult-as-int? > That seems weird and there's no comment explaining it. I'm glad you asked. :-) We use that function as a callback argument. We define the type of that argument in two places, one with an nsresult return code, the other with an int return code: http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefapi.h#157 http://mxr.mozilla.org/mozilla-central/source/modules/libpref/public/Preferences.h#29 To make things more fun, as far as I can tell the return code is never used: <http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/Preferences.cpp#164>. But that doesn't really matter, since we always return NS_OK. So I just had to pick something and move on, hence the current patch. If you don't want to accept this patch then it's fine, but please suggest an alternative. Should I make this return void?

Yes, returning void seems better than living with conflicting typedefs.

Backed out because of bustage: https://hg.mozilla.org/integration/mozilla-inbound/rev/982196bdc263

I had to edit all of the places which defined a pref callback function. https://hg.mozilla.org/integration/mozilla-inbound/rev/98be0e9cbc15