Closed Bug 676231 Opened 10 years ago Closed 10 years ago
.py generates const char* instead of char* for return values of functions that return string
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.