On Wed, Jul 13, 2016 at 6:57 PM, dandl <da...@andl.org> wrote: > > Good point, though personally I would weigh this in a different class of > > backward compatibility changes. > > I agree, but I have no evidence either way. You never really know what a > customer is doing until you change something they were using. >
Yes. But we're not talking about SQLite functionality. We're talking about an include guard. Well, several include guards in the case of the amalgamation, but defined macros that aren't used anywhere other than to protect against multiple inclusion. If anyone is using a guard to detect SQLite availability, what is going to go wrong? A change to the include guard macro would mean incorrectly detect SQLite is not available (but it really is because the guard changed) and try to compile some alternative piece of code (which could be a simple #error directive, or some alternative database management code that doesn't depend on SQLite). In either case, SQLite isn't going to start doing something different than it did previously (which would be a bad backward compatibility change). > > I don't think changing this would be bad. > > But I also don't think a change is necessary. > > > > Driving 51 in a zone posted 50 is also not in compliance (with a > different > > standard, of course). Yet we violate that standard all the time. > > > > The reality is that I'm not aware of a single platform that will fail to > > generate correct code for this (outside of treat all warnings as errors). > > Again I agree, although again one never really knows. > You're right, no one knows. However, given long standing practice not just by SQLite but by *many* libraries from *many* vendors, it is unlikely that any serious compiler vendor is going to start refusing to accept this technically invalid yet common practice. The users would be up in arms that they can't compile code that works every place else. Even the most pedantic environments that complain about various problematic constructs still allow the constructs. > > Yes, it is a standards violation in the strictest sense. Yet it's not a > big > > deal given the number of successful deployments. > > > > If anyone can demonstrate an implementation that uses this identifier in > a > > way that is incompatible with SQLite, then it should be changed. > Otherwise > it > > seems to me that disabling treat all warning as errors (or this one > warning > > in the impacted projects and files) is the least disruptive change for > all > > concerned. > > This is the core of this post, and the only part I disagree with. There are > corporate environments in which extremely tight control is maintained over > compliance and standards, and in which a decision as to how to treating > various warnings and errors raised by various development tools involves > multiple parties and multiple processes and multiple levels of approvals. > It > is simply not possible to form a blanket opinion on exactly how disruptive > such a change would be in all possible users' environments; nor should one > try. > I'm not sure how this is a disagreement. I said it probably shouldn't be changed unless or until it is identified to be an actual problem vs a theoretical problem. Warnings are not errors (in the absence of a switch promoting warnings to errors). If an environment is identified that really treats this as an error, that would be the time to consider it. It is imminently possible to form an opinion on this: unless and until someone demonstrates an actual problem, a change should not be necessary. I won't be bothered whether or not a change is made. But to suggest someone can't "try" to have an opinion on such a minor thing (and it is minor, or even infinitesimally significant, given the billions of successful installations of SQLite around the world) seems odd to me. Decisions are made all the time to try to determine how critical a "bug" or "feature" or "change" is and what impact it will have on different classes of users. In fact, that's at the root of this discussion. Would changing the spelling of an include guard (where _ is just another letter in the set of letters) improve the product or hurt existing users of the product? It might require some people to change a line of code from: #if defined(_SQLITE3_H_) to #if defined(_SQLITE3_H_) || defined(SQLITE3_H_INCLUDED) or lines to that effect. If all you meant is "you can't know how disruptive it will be across all users" then sure, you are correct. But we still have to try to quantify what might break with any change and quantify the utility of the change. If anything, it is a statement that allows one to easily argue for not making a change to an include guard where the code is currently working for so many developers / deployments. > > Regards > David M Bennett FACS > > Andl - A New Database Language - andl.org > > > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Scott Robison _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
