But does the simple solution of an if statement negatively impact performance? It may or may not, I really don't know. On the one hand, there is the overhead of the check for the condition. On the other, it avoids making a function call if the condition is false. On a third hand (I've run out, someone give me a hand) the function itself is going to make the check regardless.
I realize that performance at this level is usually negligible, but we're talking about a code base that the developers have been *very* actively trying to optimize to great effect. I guess some profiling would be in order to know if an extra if statement helps / hurts / is indifferent to performance. On Thu, Aug 20, 2015 at 10:16 AM, Bernhard Schommer < bernhardschommer at gmail.com> wrote: > Hi, > > I fully understand that removing warnings and still staying portable is > hard. > I recently had my problems with removing warnings for C code from the > Visual Studio which is a nightmare since the C support of the Visual Studio > is really bad (mixed declarations only with MSVC >= 2013). > However in this case the simple solution of adding an if statement before > removes the warning. > > Cheers, > Bernhard > > 2015-08-20 17:56 GMT+02:00 Scott Robison <scott at casaderobison.com>: > > > On Thu, Aug 20, 2015 at 9:35 AM, Bernhard Schommer < > > bernhardschommer at gmail.com> wrote: > > > > > It's not a bug. It actually comes from the warning > > -Wmemset-transposed-args > > > which is active with -Wall and I had a short look that it seems to be > > that > > > there were several bugs with false positives for this warning and as > far > > as > > > I can understand the gcc developers did not > > > rule out to issue the warning even if memset(*,0,0) is used. > > > > > > > It's not a bug as it is only a warning, but it is an overly strict > warning. > > The parameters have been confirmed to be in the correct order. This > warning > > is not unlike the ones I get from Visual C++ about "this function is > often > > misused, try this other one instead". The reality is that if the the > > function in question is being used properly, the warning can be safely > > ignored. > > > > Don't misunderstand, I am all in favor of eliminating as many warnings as > > possible, but it is a lot harder to be 100% warning free in portable > source > > like SQLite. > > > > -- > > Scott Robison > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Scott Robison
