On Fri, 18 Feb 2011 09:32:52 -0500, Black, Michael (IS) <michael.bla...@ngc.com> wrote:
> I'll agree that excessive worry is counterproductive. But when I see > warnings about pointer size mismatch and integer truncation I get > worried. So, what would you do if you found this to be the right tool for a job? http://research.swtch.com/2008/03/using-uninitialized-memory-for-fun-and.html This is the story of a clever trick that’s been around for at least 35 years, in which array values can be left uninitialized and then read during normal operations, yet the code behaves correctly no matter what garbage is sitting in the array. […] Notice what just happened: sparse can have any arbitrary values in the positions for integers not in the set, those values actually get used during membership tests, and yet the membership test behaves correctly! (This would drive valgrind nuts.) My list history shows[1] that I know how to catch real bugs on a compiler warning. But really, the signup process for this list needs a big scary TOS agreement containing the stipulation, “I promise not to complain about compiler warnings unless I have actually READ THE SOURCE CODE and found actual evidence of an actual bug.” That, with a liquidated damages provision. A FAQ[2] isn’t enough, as we can see. To put it another way: Bug reporters should have probable cause before they bug others. A compiler warning is only a reasonable articulable suspicion. Note that “probable cause” doesn’t imply computer expertise; “it crashes” is probable cause. But a compiler warning only means that a dumb piece of melted sand (i.e., a computer) running a static analysis suggested there might be perhaps something wrong with it, maybe. Not that any actual misbehavior was observed. Relying on a compiler warning means abdicating wetware to kneel in thrall at the feet of silicon dioxide. It’s wrong and it’s stupid. N.b., I am not accusing hereby Mr. Black of so relying; I just happened to reply to his message, because the uninitialized-memory trick seemed apropos of his message and I think he as a C coder would duly appreciate the argument (whether or not he agrees). But the original poster, Mr. Arief, posted an apparent copy-and-paste of such warnings with aught other said but a helpful link to where we can download MSVC Express. It happens here every few months; I am sick of it, ten thousand other list readers are probably sick of it, and it peeves the SQLite team sufficiently that they have a FAQ[2,idem] on the topic. > [snip] > If you're going to decide to ignore it then put a comment in the code > that says "don't bother to use options X/Y/Z to look for warnings...we > have chosen to ignore them". Much as I regularly take issue with other items therein, when both the FAQ[2,idem] and another document thereby referenced[3] explain SQLite’s position on compiler warnings, it is futile to expect that somebody who missed that would read a source code comment. Did I mention the FAQ[2,supra]? Very truly, Samuel Adam ◊ <http://certifound.com/> 763 Montgomery Road ◊ Hillsborough, NJ 08844-1304 ◊ United States Legal advice from a non-lawyer: “If you are sued, don’t do what the Supreme Court of New Jersey, its agents, and its officers did.” http://www.youtube.com/watch?v=iT2hEwBfU1g [1] http://www.mail-archive.com/sqlite-users@sqlite.org/msg56813.html [2] http://www.sqlite.org/faq.html#q17 [3] http://www.sqlite.org/testing.html#staticanalysis _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
