> Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I just > noticed that SQLite uses include guards with a leading underscore, for > example _SQLITE3_H_ in the amalgamation. According to the C standard, this is > a reserved identifier, leading to undefined behavior: > > > All identifiers that begin with an underscore and either an uppercase > > letter or another underscore are always reserved for any use. [...] If > > the program declares or defines an identifier in a context in which it > > is reserved (other than as allowed by 7.1.4), or defines a reserved > > identifier as a macro name, the behavior is undefined. > > (Source: the C11 standard, Section 7.1.3, see [1] for the latest draft of C11 > before publication, which should be identical to the finished text) > > I guess that means that the include guards should be changed to no longer use > leading underscores. Any opinions on that?
Yes, that's how I read it. There are I believe two potential theoretical problems. 1. An unusual but fully conforming compiler implementation could use an identifier such as this for its own purposes; the behaviour in that case would indeed be "undefined". Such an implementation could not be used "out of the box" with Sqlite. 2. A fully conforming compiler implementation might treat the use of such an identifier as a defect and issue a diagnostic. Although this would most likely be at a warning level, such a compiler could not be used with Sqlite in an environment where all warnings are automatically treated as errors. The first of these is quite unlikely; the second is quite likely (and may be the situation OP has encountered). Obviously there are workarounds in both cases. Nevertheless I would tend to regard this as a bug. 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
