When generating this idl: http://hg.mozilla.org/comm-central/annotate/4f6a003e6273/mailnews/addrbook/public/nsIMsgVCardService.idl the new xpidl.py generates different signatures for some of the functions: /* [noscript,notxpcom] string fakeCString (in VObject_ptr o); */ NS_IMETHOD_(const char *) FakeCString(VObject *o) = 0; /* [noscript,notxpcom] string writeMemoryVObjects (in string s, out long len, in VObject_ptr list, in boolean expandSpaces); */ NS_IMETHOD_(const char *) WriteMemoryVObjects(const char * s, PRInt32 *len NS_OUTPARAM, VObject *list, PRBool expandSpaces) = 0; /* [noscript,notxpcom] string vObjectAnyValue (in VObject_ptr o); */ NS_IMETHOD_(const char *) VObjectAnyValue(VObject *o) = 0; I found this after applying bug 578478 to comm-central.

Hrm, notxpcom return values are in that grey area. I'd argue that the pyxpcom way is probably more correct, but that may not be worth worrying about. You'll have to alter http://mxr.mozilla.org/mozilla-central/source/xpcom/idl-parser/header.py#107 (and #102) somehow, it uses 'in' when you really want something else which is neither in nor out...

I think the better solution here would be to return "charPtr" instead of "string".

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > I think the better solution here would be to return "charPtr" instead of > "string". Mark, does that fix the issue here?

Yes that works, and is a much clearer statement as well.