On Sat, Aug 22, 2015 at 10:31 AM, Richard Hipp <drh at sqlite.org> wrote:
> On 8/22/15, Scott Robison <scott at casaderobison.com> wrote: > > I don't object to a change to accommodate C99 null > > pointer requirements > > Please note that the warning in question has nothing to do with NULL > pointers. The pointer parameter (0) is non-null. The issue is that > the last parameter (2) which is a size_t might sometimes be zero and > the compiler felt compelled to share that bit of knowledge, thinking > that we might have meant to put the zero in the penultimate parameter > (1) which is of type int. > I understand that. I was just using that as an example of a relatively recent change that was made to accommodate C99. I know this more recent warning has nothing to do with standards compliance. The similarity just has to do with making changes to an ANSI-C code base ( https://www.sqlite.org/howtocompile.html) to accommodate non-ANSI-C compilers or compilers which issue warnings for cases which they are not "smart enough" to recognize the context. This is why they are warnings in the first place. If the compiler knew with absolute certainty that the code in question was erroneous, I have to believe they'd issue an error instead. They don't / can't know this, so they issue a "hey, you'd better double check this, but I'll defer to your judgement" message instead. Just yesterday we had a member of our build team report that a build was broken to a dev in a neighboring cubicle. It was broken because warnings were being treated as errors in the build system, and there was a warning in a third party library we use (not SQLite). As I've said before, I'm all for trying to eliminate all warnings, and that is what I strive to do. Sometimes you have to suppress the warning (or start maintaining patches to a third party code base). There are often ways to do so in a fine grained way so that you don't lose the value of the warning in all cases, just those you've confirmed are valid. And there are warnings that are worthless and must be suppressed completely (such as the Visual C++ warnings having to do with safety of certain standard library functions; the same is true of OpenBSD, and many others I am sure). If I am trying to write portable code that can build in many varying environments, I need to use standard library functions at times, not environment specific replacements. Or pepper my code with conditionals, or abstract away all functions that might generate warnings into a set of shims, or whatever. I prefer to just use the standard functions the way they were intended. Not that you were claiming otherwise. I'll stop raving like a lunatic now. -- Scott Robison
