Sorry I should've noticed that 855335 is a sec-bug. It's title is "Audit SIPCC printf-style format strings" which means we went through every logging call and repaired a few which had incorrect printf-style args.
-EH On Fri, Aug 2, 2013 at 2:44 PM, Justin Lebar <justin.le...@gmail.com> wrote: > > I agree that iostream-based logging would be safer. If we had it I > > wouldn't have had to work on this one: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=855335 > > I can't access that bug, but maybe you mean > https://bugzilla.mozilla.org/show_bug.cgi?id=onelogger ? > > I feel like the goals there are orthogonal to NSPR vs iostream. > > I haven't had a chance to work on this lately, but I do intend to land > something when I can. > > On Fri, Aug 2, 2013 at 2:41 PM, Ethan Hugg <ethanh...@gmail.com> wrote: > >>It is very useful for building a logging interface that is safer and more > >>convenient than NSPR's printf-style logging. Note that, again, Eric > >>Rescorla already built an (partial) iostream-based wrapper around NSPR > for > >>WebRTC. I would say that, if there is no additional overhead, then we > >>should consider making iostream-based logging the default way of doing > >>things in Gecko because it is so much less error-prone. > > > > I found this comment interesting. It wasn't that long ago I was > instructed > > to get rid of all iostream-based logging from media/webrtc/signaling and > > media/mtransport if it we wanted the logging to appear in opt builds. > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=795126 > > https://bugzilla.mozilla.org/show_bug.cgi?id=841899 > > > > I agree that iostream-based logging would be safer. If we had it I > > wouldn't have had to work on this one: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=855335 > > > > Can we now use iostreams throughout this code? > > > > -EH > > > > > > > > > > On Fri, Aug 2, 2013 at 2:21 PM, Brian Smith <br...@briansmith.org> > wrote: > > > >> On Wed, Jul 31, 2013 at 7:41 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com > >> >wrote: > >> > >> > implementation, libc++, libstdc++, and stlport. Since most nice > charts of > >> > C++11 compatibility focus on what the compiler needs to do, I've put > >> > together a high-level overview of the major additions to the standard > >> > library [3]: > >> > * std::function/std::bind -- Generalization of function pointers > >> > > >> > >> Note that Eric Rescorla implemented his own std::bind polyfill when he > was > >> working on WebRTC. I also have some new code I am working on where > >> std::bind is extremely helpful. > >> > >> > >> > Now that you have the background for what is or will be in standard > C++, > >> > let me discuss the real question I want to discuss: how much of this > >> should > >> > we be using in Mozilla? > >> > > >> > >> > >> > For purposes of discussion, I think it's worth breaking down the C++ > (and > >> > C) standard library into the following components: > >> > * Containers--vector, map, etc. > >> > * Strings > >> > * I/O > >> > * Platform support (threading, networking, filesystems, locales) > >> > * Other helpful utilities (std::random, std::tuple, etc.) > >> > > >> > The iostream library has some issues with using (particularly static > >> > constructors IIRC), and is not so usable for most of the things that > >> Gecko > >> > needs to do. > >> > >> > >> It is very useful for building a logging interface that is safer and > more > >> convenient than NSPR's printf-style logging. Note that, again, Eric > >> Rescorla already built an (partial) iostream-based wrapper around NSPR > for > >> WebRTC. I would say that, if there is no additional overhead, then we > >> should consider making iostream-based logging the default way of doing > >> things in Gecko because it is so much less error-prone. > >> > >> > >> > Even if fully using the standard library is untenable from a > performance > >> > perspective, usability may be enhanced if we align some of our APIs > which > >> > mimic STL functionality with the actual STL APIs. For example, we > could > >> add > >> > begin()/end()/push_back()/etc. methods to nsTArray to make it a fairly > >> > drop-in replacement for std::vector, or at least close enough to one > that > >> > it could be used in other STL APIs (like std::sort, std::find, etc.). > >> > However, this does create massive incongruities in our API, since the > >> > standard library prefers naming stuff with this_kind_of_convention > >> whereas > >> > most Mozilla style guides prefer ThisKindOfConvention. > >> > > >> > >> Perhaps a more annoying issue--though not a showstoper--is that > >> unique_ptr::release() means something quite different than > >> nsXXXPtr::Release() means. > >> > >> > >> > With all of that stated, the questions I want to pose to the > community at > >> > large are as follows: > >> > 1. How much, and where, should we be using standard C++ library > >> > functionality in Mozilla code? > >> > > >> > >> We should definitely prefer using the standard C++ library over writing > any > >> new code for MFBT, *unless* there is consensus that the new thing we'd > do > >> in MFBT is substantially clearer. (For example, I think some people > >> successfully argued that we should have our own atomic types because our > >> interface is clearly better than std::atomic.) > >> > >> Even in the case where MFBT or XPCOM stuff is generally better, We > should > >> *allow* using the standard C++ library anywhere that has additional > >> constraints that warrant a different tradeoff; e.g. needing to be built > >> separately from Gecko and/or otherwise needing to minimize Gecko > >> dependencies. > >> > >> > >> > 3. How should we handle bridge support for standardized features not > yet > >> > universally-implemented? > >> > > >> > >> Generally, I would much rather we implement std::whatever ourselves than > >> implement mozilla::Whatever, all other things being equal. This saves us > >> from the massive rewrites later to s/mozilla::Whatever/std::whatever/; > >> while such rewrites are generally a net win, they are still disruptive > >> enough to warrant trying to avoid them when possible. In the case where > it > >> is just STLPort being behind, we should just add the thing to STLPort > (and > >> try to upstream it). in the case where the lack of support for a useful > >> standard library feature is more widespread, we should still implement > >> std::whatever if the language support we have enables us to do so. I am > not > >> sure where such implementations should live. > >> > >> > >> > 4. When should we prefer our own implementations to standard library > >> > implementations? > >> > > >> > >> It is a judgement call. The default should be to use standard library > >> functions, but we shouldn't be shy about using our own stuff if it is > >> clearly better. On the other side, we shouldn't be shy about replacing > uses > >> of same-thing-but-different Mozilla-specific libraries with uses of the > >> standard libraries, all things being equal. > >> > >> > >> > 5. To what degree should our platform-bridging libraries > >> > (xpcom/mfbt/necko/nspr) use or align with the C++ standard library? > >> > > >> > >> I am not sure why you include Necko in that list. Did you mean NSS? For > >> NSPR and NSS, I would like to include some very basic utilities like > >> ScopedPRFileDesc that are included directly in NSPR/NSS, so that we can > use > >> them in GTest-based tests, even if NSPR and NSS otherwise stick with C. > >> But, I don't know if the module owners of those modules will accept > them. > >> > >> > >> > 6. Where support for an API we wish to use is not universal, what is > the > >> > preferred way to mock that support? > >> > [Note: similar questions also apply to NSPR and NSS with respect to > newer > >> > C99 and C11 functionality.] > >> > > >> > >> There is no tolerance for mass changes like s/PRInt32/int32_t/ in NSPR > or > >> NSS, AFAICT. C99 and C11 are basically off the table too, because > Microsoft > >> refuses to support them in MSVC. > >> > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
