nsIDebug.idl and nsITraceRefcount.idl are part of the SDK, but not marked frozen. since they are @status UNDER_REVIEW, maybe they should just be marked frozen?
Yes, these must be marked frozen. Moreover, we have NS_GetDebug and NS_GetTraceRefcnt that need to be marked frozen if they are not already marked as such. There may be a few other functions in nsXPCOMPrivate.h that need similar loving.
I believe we should definitely freeze nsIDebug the way it is. Is nsITraceRefCnt debug-only? I'm a lot less certain about that one.
i do not think nsITraceRefcount or nsIDebug.idl should be part of the SDK. I remember adding this as a private interface between the xpcom library and the xpcom glue library -- something not intended for general use by developers.
If the glue uses them, they need to be frozen, since changing them would break old clients of the glue. We could do @status FROZEN + PRIVATE
Or, are these interfaces only needed in --enable-debug builds? Can we make them not be used when the glue is compiled with MOZILLA_STRICT_API?
@status FROZEN + PRIVATE is fine with me... something can be frozen and not put into the public SDK. Darin is also right, these are only used in debug (or only should be used when in a debug bug). I do not see how MOZILLA_STRICT_API has anything to do with this.
> Darin is also right, these are only used in debug (or only should be used when > in a debug bug). I do not see how MOZILLA_STRICT_API has anything to do with > this. Doug: effective a month or so ago, we now build the two versions of glue library that are included in the SDK with MOZILLA_STRICT_API defined. that was done so that those glue libraries would use the frozen string API. however, the glue library that is linked into libxpcom_core (or libxul), is compiled against the unfrozen internal string API. this was also done so that external components could be linked cleanly against libxpcom_glue.a + libxpcom.so. So, this means that we could #ifdef the glue code to only use nsIDebug and nsITraceRefcnt when MOZILLA_STRICT_API is not defined. This seems like a good idea to me because it is likely that users of the Gecko SDK may themselves #define DEBUG for their own users. If our headers see that and start using nsIDebug or nsITraceRefcnt, then that could cause problems. Make sense?
so, i want to write a xpcom component using MOZILLA_STRICT_API. during development, i want to see if I am leaking and if so, do something about it. what you are proposing would have me disable MOZILLA_STRICT_API.
Well, we could always have another #ifdef that selectively enables nsITraceRefcnt and/or nsIDebug, but unless we are going to freeze those interfaces, then it seems like they should not be used when MOZILLA_STRICT_API is defined.
Those interfaces are being used between the xpcom glue library and the xpcom library -- not by the user. The class, nsDebug and nsTrace(something), use them internally.
> Those interfaces are being used between the xpcom glue library and the xpcom > library -- not by the user. The class, nsDebug and nsTrace(something), use > them internally. Yes, but that does not change the fact that a consumer's binary (component or exe) will have a dependency on those interfaces. Therefore, we cannot change those interfaces, and they are effectively frozen. So, either we freeze them or we make it so that by default consumers do not "use" them (by linking to a static library that uses them or otherwise) when they say that they only want to use frozen interfaces (i.e., when they define MOZILLA_STRICT_API).
Darin -- my point is, they are frozen and they are not part of the SDK for general use. MOZILLA_STRICT_API should not hide these two interfaces.
mass reassigning to nobody.
Assignee: dougt → nobody
Components.classes["@mozilla.org/xpcom/debug;1"].getService(Components.interfaces.nsIDebug) WFM in nightlies. And this bug, being about frozen interfaces, is no longer useful since we no longer have frozen interfaces.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.