> We change internal-use #defines and other internal-use symbols on just
about
> every release. This has never before caused breakage that we are aware
of.
> Or if it has caused breakage, the developers doing such things are aware
that
> what they are doing is not allowed and have the good sense t
On 7/14/16, Darren Duncan wrote:
>
> My recommendation on this matter is to deprecate but retain the current
> include
> guards that are in violation of the standard, and ALSO add new, redundant
> include guards in a manner that comply with the standard.
>
> Thoughts on that proposal?
>
We change
On 2016-07-12 9:32 PM, Cory Nelson wrote:
On Fri, Jul 8, 2016 at 6:56 PM, Daniel Seither wrote:
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
On Wed, Jul 13, 2016 at 6:57 PM, dandl 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 usin
> 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.
> I don't think changing this would be bad.
> But I
On Jul 12, 2016 10:32 PM, "Cory Nelson" wrote:
>
> While uncommon, it is not unheard of for apps to use include guards to
> check for a library's existence. While it is indeed not in compliance,
> in practice fixing this may affect existing SQLite users.
Good point, though personally I would weig
On Fri, Jul 8, 2016 at 6:56 PM, Daniel Seither wrote:
> 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 i
On 7/12/16 12:58 AM, dandl wrote:
Try to write a fully standard compliant standard library without using any
of
the reserved namespace!!!
This is the key point that has been missed so far. The C/C++ standards do
not provide a mechanism by which the supplier of a library can reserve or
sequeste
> Try to write a fully standard compliant standard library without using any
of
> the reserved namespace!!!
This is the key point that has been missed so far. The C/C++ standards do
not provide a mechanism by which the supplier of a library can reserve or
sequester some range of identifiers, for b
On 7/9/16 11:47 PM, J Decker wrote:
Okay if this should change, I would recommand a new standard for all
libraries; and since standards are so important maybe make them know about
it too...
do ... ORG_DOMAIN_APPLICATION_LIBRARY_MODULE_SOURCE_INCLUDED
where each piece becomes unqiqe so there's
Okay if this should change, I would recommand a new standard for all
libraries; and since standards are so important maybe make them know about
it too...
do ... ORG_DOMAIN_APPLICATION_LIBRARY_MODULE_SOURCE_INCLUDED
where each piece becomes unqiqe so there's no collision. I'd expect
compilers th
> Obviously the standard is broken/incorrect or your interpretation of it is
> broken/incorrect.
No, and the standard was very carefully written to say this, and it's easy
to find references to back up this interpretation if you care to look for
them. Or ask a question on SO.
> Most API headers d
On Fri, Jul 8, 2016 at 4:56 PM, Daniel Seither wrote:
> 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
On Sat, Jul 9, 2016 at 12:05 PM, Keith Medcalf wrote:
>
> [...] Most API headers do the same thing. Even the standard library does
> it, in most compilers. [...]
Sure, that's why they're reserved! So user code and the C compiler's
library implementation don't clash. The C standard reserves th
6 17:56
> To: sqlite-users@mailinglists.sqlite.org
> Subject: [sqlite] Bug: SQLite's include guards are reserved identifiers
>
> Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I
> just noticed that SQLite uses include guards with a leading underscore,
> 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 id
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 th
17 matches
Mail list logo
