================
Comment at: lib/Basic/LangOptions.cpp:17-21
@@ -16,3 +16,7 @@
-const SanitizerOptions SanitizerOptions::Disabled = {};
+const SanitizerOptions SanitizerOptions::Disabled = {
+#define SANITIZER(NAME, ID) 0,
+#include "clang/Basic/Sanitizers.def"
+};
+
----------------
Edwin Vane wrote:
> Dmitri Gribenko wrote:
> > Edwin Vane wrote:
> > > Dmitri Gribenko wrote:
> > > > David Blaikie wrote:
> > > > > Not sure of the motivation for this change - shouldn't the {} in the
> > > > > original code produce the same effect (zero initializing all the
> > > > > elements)?
> > > > I have mixed feelings about this. -Wmissing-field-initializers is a
> > > > different thing: all members are initialized by {}, but gcc complains
> > > > that initializers are not explicitly spelled in the source.
> > > Is it a problem to explicitly do the initialization to make gcc happy if
> > > it has the same result as {}? I wasn't aware empty braces was defined to
> > > cause all fields to be initialized to 0.
> > It just adds noise to satisfy the warning. In this particular case it is
> > not actually that bad, since SanitizerOptions is generated by the same .def
> > file, so it will not go out of sync.
> >
> Would you prefer using default constructor instead? At least I was able to
> find defined behaviour for this situation:
>
> const SanitizerOptions SanitizerOptions::Disabled = SanitizerOptions();
This is dynamic initialization, if I'm reading [basic.init.start] correctly.
(But Clang does it as static initialization because it is allowed to do so, but
not required.) #define/#include is better.
http://llvm-reviews.chandlerc.com/D342
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
