On Fri, Mar 18, 2016 at 4:03 PM, Richard Hipp <drh at sqlite.org> wrote:
> On 3/18/16, Igor Tandetnik <igor at tandetnik.org> wrote: > > On 3/18/2016 4:40 PM, Keith Medcalf wrote: > >> There is no such thing as "undefined behaviour". The machine code does > >> exactly what it is told to do > > > > But SQLite is not written in machine code. It is (largely) written in C. > > SQLite is written in C, but the focus of testing is the resulting > machine code. So, there is a point of view that says that it doesn't > really matter if the C code is "undefined" or not. What matters is > whether or not the resulting machine code computes the correct answer. > That's what we test: does the machine code compute the correct answer. > > That said, we also do source-code validation on SQLite. We work to > make SQLite compile without warnings, we run it through static > analyzers, and I address any "undefined behaviors" in the source code > that John Regehr or others report. SQLite contains thousands of > I'd rather have code that might use some "undefined behavior" and generates the right answer than code that always conformed to defined behavior yet was logically flawed. Mind you, I don't often have to worry about my code being compiled in a huge number of environments. Also, it seems a lot of people today are critical of programs that utilize defined behavior in the context of the standard to which they were written, but not to a later standard (such as ANSI C / C89 / C90 vs C99 or C11 or whatever). It's great to conform to both when reasonable, but it may not always be reasonable (as I can't necessarily conceive of every possibility). -- Scott Robison
