Re: [sqlite] Errors opening WAL-based databases with SQLITE_OPEN_READONLY

[Simon Slavin]

On 11 Apr 2017, at 12:22am, Jens Alfke  wrote:

> It only states that the process must be able to create/write the -shm file. 
> It doesn't say anything about opening the database with SQLITE_OPEN_READONLY

The problem here is not whether you’re allowing SQLite to make changes to your 
data, but whether the OS is allowing SQLite to write to its files.  You should 
regard SQLITE_OPEN_READONLY as telling SQLite whether it’s allowed to change 
the database.  It doesn’t tell SQLite how it should work internally, just 
whether it’s allowed to execute commands like CREATE and UPDATE.

Don’t try to open a database which has WAL mode set unless you have write 
permission to the database file, journal file and shared memory file.  (Or 
create new files, then write to them).

It may be that the documentation should be updated to reflect this.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Errors opening WAL-based databases with SQLITE_OPEN_READONLY

[Jens Alfke]

> On Apr 10, 2017, at 2:21 PM, J. King  wrote:
> 
> It is not possible to open read-only WAL databases. The opening process must 
> have write privileges for "-shm" wal-index shared memory file associated with 
> the database, if that file exists, or else write access on the directory 
> containing the database file if the "-shm" file does not exist. 

Yes, that's the documentation I was referring to. It only states that the 
process must be able to create/write the -shm file. It doesn't say anything 
about opening the database with SQLITE_OPEN_READONLY.

IMHO, since the -shm file is only a cross-process temporary index of the WAL 
file, SQLite should be allowed to create this file even if the database itself 
is read-only. Otherwise opening a database read-only will sometimes succeed and 
sometimes fail on a writeable filesystem, depending on whether or not the -shm 
file already exists. This caused me some confusion this morning — I was running 
new test code that reads a number of existing sample databases, and some of 
them would mysteriously fail to open. Even weirder, after I inspected a problem 
database using the `sqlite3` tool, the problem with it went away! (Of course, 
the tool was creating the missing -shm and -wal files when it opened the file…)

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Errors opening WAL-based databases with SQLITE_OPEN_READONLY

[J. King]

On April 10, 2017 5:14:23 PM EDT, Jens Alfke  wrote:
>I'm aware that a database in WAL mode can't be opened read-only if its
>directory isn't writeable[1]. However, I'm unexpectedly getting errors
>opening a database when the directory _is_ writeable, but the database
>is opened read-only. Specifically:
>
>* The database file is in WAL mode.
>* The -wal and -shm files do not exist (i.e. the database was
>previously closed cleanly.)
>* The directory containing the database is writeable (i.e. the process
>is allowed to create files in it.)
>* The database is opened with sqlite3_open_v2, using the
>SQLITE_OPEN_READONLY flag.
>
>In this situation, any SQLite call that actually accesses the database
>will fail with SQLITE_CANTOPEN.
>
>It seems as though SQLite decides that because the handle is read-only,
>it's not allowed to create the -shm file. There's some logic to this,
>but I can't find any mention of it in the documentation.
>
>(I'm using SQLite 3.16 on macOS 10.12.4.)
>
>—Jens
>
>[1]: https://www.sqlite.org/wal.html#readonly
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

WAL databases must be opened read/write because readers need to write to the 
shm file. It is in the documention on WAL mode:

It is not possible to open read-only WAL databases. The opening process must 
have write privileges for "-shm" wal-index shared memory file associated with 
the database, if that file exists, or else write access on the directory 
containing the database file if the "-shm" file does not exist. 
-- 
J. King
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Errors opening WAL-based databases with SQLITE_OPEN_READONLY

[Jens Alfke]

I'm aware that a database in WAL mode can't be opened read-only if its 
directory isn't writeable[1]. However, I'm unexpectedly getting errors opening 
a database when the directory _is_ writeable, but the database is opened 
read-only. Specifically:

* The database file is in WAL mode.
* The -wal and -shm files do not exist (i.e. the database was previously closed 
cleanly.)
* The directory containing the database is writeable (i.e. the process is 
allowed to create files in it.)
* The database is opened with sqlite3_open_v2, using the SQLITE_OPEN_READONLY 
flag.

In this situation, any SQLite call that actually accesses the database will 
fail with SQLITE_CANTOPEN.

It seems as though SQLite decides that because the handle is read-only, it's 
not allowed to create the -shm file. There's some logic to this, but I can't 
find any mention of it in the documentation.

(I'm using SQLite 3.16 on macOS 10.12.4.)

—Jens

[1]: https://www.sqlite.org/wal.html#readonly
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3_step and ORDER BY random() question.

[Simon Slavin]

On 10 Apr 2017, at 9:28pm, Reid Thompson  wrote:

> my questions are, if I prepare and utilize a statement for a result set
> in the tens of thousands (or more) using a where clause along the lines
> of
>"ORDER BY batch_id, due_datetime, random()"
> 
> 1) As I sqlite3_step through the result set, am I guaranteed to get each
> row only once?

Yes.  _step() will return each row exactly once.  This assumes you will not 
make any changes to the table those rows are in until you have finished 
stepping.  If you make any changes to the table before the last call to _step() 
then things may get more complicated.

> 2) is the order set only once on the first sqlite3_step, or does it
> change with each sqlite3_step invocation?

Because no index already exists for that ORDER, you can imagine that SQLite 
makes up a temporary index for the results when you do the first 
sqlite3_step(), and deletes it when you execute sqlite3_reset() or 
sqlite3_finalize().

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] sqlite3_step and ORDER BY random() question.

[Reid Thompson]

hi, and thanks.

my questions are, if I prepare and utilize a statement for a result set
in the tens of thousands (or more) using a where clause along the lines
of
   "ORDER BY batch_id, due_datetime, random()"

1) As I sqlite3_step through the result set, am I guaranteed to get each
row only once?

2) is the order set only once on the first sqlite3_step, or does it
change with each sqlite3_step invocation?

thanks,
reid

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

ok, but then
namespace ns1
{
extern "C" int ert(void) { return 9; }
};

namespace ns2
{
extern "C" int ert(void);
};

are both the same function !

it would be simpler in the sqlite case to define Mem to something else
before include, and then undef it

instead of playing with namespace


2017-04-10 10:43 GMT-04:00 Olivier Mascia :

> > Le 10 avr. 2017 à 16:21, Daniel Anderson  a écrit :
> >
> > as Sqlite is already within extern "C"
> >
> > I'm wondering how your namespace trick can work ?
>
>
> Both are simply unrelated.
> extern "C" is a linkage specification.
> Not a namespace declaration.
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia, http://integral.software
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] json() number value parsing

[Jens Alfke]

> On Apr 10, 2017, at 6:37 AM, Dominique Devienne  wrote:
> 
> I ran into http://json5.org/  which is an interesting 
> "for-humans" extension to JSON.

I love JSON5. It’s an extension of JSON that adds extra syntax from JavaScript, 
like single quotes, trailing commas, and unquoted alphanumeric keys. I find it 
much more readable and much easier to write. A key benefit is that, by using 
single quotes, you can embed JSON5 in a C/C++/Swift/etc. string literal without 
having to escape all those pesky double-quotes:

const char *json  = "{\"foo\": \"bar\"}";
const char *json5 = "{foo: 'bar'}";

FYI, I wrote a converter in C++ that translates JSON5 to JSON. I use it a lot 
in unit tests in my code. It's also useful when parsing configuration files 
that are likely to be human-written or -edited.
https://github.com/couchbaselabs/fleece/blob/master/Fleece/JSON5.hh
https://github.com/couchbaselabs/fleece/blob/master/Fleece/JSON5.cc

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Olivier Mascia]

> Le 10 avr. 2017 à 16:21, Daniel Anderson  a écrit :
> 
> as Sqlite is already within extern "C"
> 
> I'm wondering how your namespace trick can work ?


Both are simply unrelated.
extern "C" is a linkage specification.
Not a namespace declaration.

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia, http://integral.software


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

as Sqlite is already within extern "C"

I'm wondering how your namespace trick can work ?



2017-04-10 9:41 GMT-04:00 Bob Friesenhahn :

> On Mon, 10 Apr 2017, Olivier Mascia wrote:
>
>>
>> This is where I do:
>>
>> #include "memory.h"
>> namespace sqlite
>> {
>> #include "sqlite3.h"
>> }
>>
>> And the conflict with your Mem goes away for the price of qualifying your
>> references to SQLite symbols with 'sqlite::'. It fits me easily because we
>> have our own slim C++ wrapper around SQLite C API, so these prefixed
>> references are only slightly annoying (length of text) in the wrapper code.
>> It might of course not fit you and having sqlite3.h not exposing that Mem
>> in the public namespace is certainly the long term better solution for
>> everyone.
>>
>
> A way to get rid of the annoying 'sqlite::' prefix for plain C functions
> is to import the functions actually planned to be used into global scope or
> into the namespace of the using code:
>
> namespace MyNamespace
> {
>   using sqlite:sqlite3_exec;
> }
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Bob Friesenhahn]

On Mon, 10 Apr 2017, Olivier Mascia wrote:


This is where I do:

#include "memory.h"
namespace sqlite
{
#include "sqlite3.h"
}

And the conflict with your Mem goes away for the price of qualifying 
your references to SQLite symbols with 'sqlite::'. It fits me easily 
because we have our own slim C++ wrapper around SQLite C API, so 
these prefixed references are only slightly annoying (length of 
text) in the wrapper code. It might of course not fit you and having 
sqlite3.h not exposing that Mem in the public namespace is certainly 
the long term better solution for everyone.


A way to get rid of the annoying 'sqlite::' prefix for plain C 
functions is to import the functions actually planned to be used into 
global scope or into the namespace of the using code:


namespace MyNamespace
{
  using sqlite:sqlite3_exec;
}

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] json() number value parsing

[Dominique Devienne]

On Mon, Apr 10, 2017 at 2:27 PM, Richard Hipp  wrote:

> On 4/10/17, Richard Hipp  wrote:
> > SQLite returns true from json_valid() for the following cases which
> > should allegedly be false:
> >
> >   n_multidigit_number_then_00.json
> >   n_string_unescaped_newline.json
> >   n_string_unescaped_tab.json
> >
>
> The second and third are now fixed on trunk.
>
> The first test case consists of a valid JSON with an extra 0x00
> terminator.  As SQLite interprets the 0x00 as an end-of-string marker,
> I do not see this one as an error.


Great! Thanks Richard.

FWIW, looking for whether trailing zeros for the fractional part of reals
was OK,
(seems like they are), I ran into http://json5.org/ which is an interesting
"for-humans" extension to JSON. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] json() number value parsing

[Richard Hipp]

On 4/10/17, Richard Hipp  wrote:
> SQLite returns true from json_valid() for the following cases which
> should allegedly be false:
>
>   n_multidigit_number_then_00.json
>   n_string_unescaped_newline.json
>   n_string_unescaped_tab.json
>

The second and third are now fixed on trunk.

The first test case consists of a valid JSON with an extra 0x00
terminator.  As SQLite interprets the 0x00 as an end-of-string marker,
I do not see this one as an error.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] json() number value parsing

[Richard Hipp]

On 4/10/17, Dominique Pellé  wrote:
>
> SQLite json could be added to https://github.com/nst/JSONTestSuite
> (in the parsers/ directory).
>

Thanks for the pointer.  I did not know about that project.

SQLite returns true from json_valid() for the following cases which
should allegedly be false:

  n_multidigit_number_then_00.json
  n_string_unescaped_newline.json
  n_string_unescaped_tab.json

This is the script that I ran to produce the results above:

CREATE TABLE files(name);
.mode csv
.import '| ls *.json' files

-- mal-formed JSON that json_valid shows as correct.
SELECT name FROM files
 WHERE name LIKE 'n_%'
  AND json_valid(readfile(name));

-- well-formed JSON that json_valid shows as incorrect.
SELECT name FROM files
 WHERE name LIKE 'y_%'
  AND NOT json_valid(readfile(name));

-- implementation-defined JSON does not cause crashes
SELECT name FROM files
 WHERE name LIKE 'i_%'
   AND json_valid(readfile(name)) NOT IN (0,1);

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] json() number value parsing

[Dominique Pellé]

Dominique Devienne  wrote:

> On Sun, Apr 9, 2017 at 10:34 AM, Olivier Mascia  wrote:
>
>> > Le 9 avr. 2017 à 03:08, Jens Alfke  a écrit :
>> >
>> >> On Apr 7, 2017, at 5:26 PM, Rolf Ade  wrote:
>> >> ./sqlite3
>> >> SQLite version 3.19.0 2017-04-07 20:20:08
>> >> [...]
>> >> sqlite> select json(' { "this" : 000.23 } ');
>> >> {"this":000.23}
>> >> If I read RFC 7159 (http://www.rfc-editor.org/rfc/rfc7159.txt <
>> http://www.rfc-editor.org/rfc/rfc7159.txt>) correct
>> >> this should return: "Error: malformed JSON".
>> >
>> > In this case I would go with Postel’s Law, paraphrased as “Be strict in
>> what you write, but lenient in what you read.” I don’t see a point in
>> disallowing something as trivial as redundant leading zeroes.
>>
>> If you'd go with Postal's Law, you would make it so:
>>
>> sqlite> select json(' { "this" : 000.23 } ');   // be lenient in what you
>> read
>> {"this":0.23}   // be strict in what you
>> write
>>
>
> I disagree. There's a spec. it should be followed, by default.
>
> A separate, explicitly enabled "lenient mode" could be added,
> for leading zeros, NaNs, C-comments, binary strings, etc...
> but it should not be the default.
>
> Otherwise you end up forever having to support non-conformity,
> possibly simply because of an oversights.
>
> Plus json_valid() is then lying about checking well-formed'ness. --DD
>
> sqlite> select json_valid('');
> 0
> sqlite> select json_valid('00.1');
> 1
> sqlite> select json_valid('0.1');
> 1
> sqlite> select json_valid('[]');
> 1
> sqlite> select json_valid('[00]');
> 1
> sqlite> select json_valid('[00.00]');
> 1


SQLite json could be added to https://github.com/nst/JSONTestSuite
(in the parsers/ directory).

This JSON test suite checks many kinds of invalid and valid JSON
inputs to make sure that they are rejected or accepted as expected
by RFC 7159. It surprisingly finds issues in many JSON parsers.

Dominique
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Olivier Mascia]

> Le 10 avr. 2017 à 11:11, dip  a écrit :
> 
> I am mixing C and C++ code. My code is in C++, SQLite is in C.
> Just create memory.h:
> 
> namespace Mem {
> // some functions
> }
> 
> And create code.cpp:
> 
> #include "memory.h"
> #include "sqlite3.h"
> 
> void Func()
> {
> Mem::SomeFunc(); // gives the compilation error
> }

This is where I do:

#include "memory.h"
namespace sqlite
{
#include "sqlite3.h"
}

And the conflict with your Mem goes away for the price of qualifying your 
references to SQLite symbols with 'sqlite::'. It fits me easily because we have 
our own slim C++ wrapper around SQLite C API, so these prefixed references are 
only slightly annoying (length of text) in the wrapper code. It might of course 
not fit you and having sqlite3.h not exposing that Mem in the public namespace 
is certainly the long term better solution for everyone.

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia, http://integral.software



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] json() number value parsing

[Dominique Devienne]

On Sun, Apr 9, 2017 at 10:34 AM, Olivier Mascia  wrote:

> > Le 9 avr. 2017 à 03:08, Jens Alfke  a écrit :
> >
> >> On Apr 7, 2017, at 5:26 PM, Rolf Ade  wrote:
> >> ./sqlite3
> >> SQLite version 3.19.0 2017-04-07 20:20:08
> >> [...]
> >> sqlite> select json(' { "this" : 000.23 } ');
> >> {"this":000.23}
> >> If I read RFC 7159 (http://www.rfc-editor.org/rfc/rfc7159.txt <
> http://www.rfc-editor.org/rfc/rfc7159.txt>) correct
> >> this should return: "Error: malformed JSON".
> >
> > In this case I would go with Postel’s Law, paraphrased as “Be strict in
> what you write, but lenient in what you read.” I don’t see a point in
> disallowing something as trivial as redundant leading zeroes.
>
> If you'd go with Postal's Law, you would make it so:
>
> sqlite> select json(' { "this" : 000.23 } ');   // be lenient in what you
> read
> {"this":0.23}   // be strict in what you
> write
>

I disagree. There's a spec. it should be followed, by default.

A separate, explicitly enabled "lenient mode" could be added,
for leading zeros, NaNs, C-comments, binary strings, etc...
but it should not be the default.

Otherwise you end up forever having to support non-conformity,
possibly simply because of an oversights.

Plus json_valid() is then lying about checking well-formed'ness. --DD

sqlite> select json_valid('');
0
sqlite> select json_valid('00.1');
1
sqlite> select json_valid('0.1');
1
sqlite> select json_valid('[]');
1
sqlite> select json_valid('[00]');
1
sqlite> select json_valid('[00.00]');
1
sqlite>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

Ah, understood.

I thought you had a struct or a class named Mem.


then short term solution is to rename Mem in sqlite.h

using the #define directive + include file should do the trick.

as they say solve it by using a level of indirection!

It will be a bit ugly, but until
a) sqlite change the name
or
b) you change the namespace name

you'll be stuck with a hack!

Cordialement!

Daniel


2017-04-10 5:11 GMT-04:00 dip :

> I am mixing C and C++ code. My code is in C++, SQLite is in C.
> Just create memory.h:
>
> namespace Mem {
> // some functions
> }
>
> And create code.cpp:
>
> #include "memory.h"
> #include "sqlite3.h"
>
> void Func()
> {
> Mem::SomeFunc(); // gives the compilation error
> }
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>  Original Message 
> Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes
> having the same name
> Local Time: April 10, 2017 2:29 AM
> UTC Time: April 9, 2017 11:29 PM
> From: woni...@gmail.com
> To: SQLite mailing list 
>
> I see no problems with C++.
>
> Mem is only foward declared, you can redefined it to whatever you want. as
> long as you do not redefined it for sqlite.c you should be good.
>
> in sqlite.h it's declared:
>
> struct Mem;
>
> so in your code if you do:
>
> struct Mem { int a;int b;} then your definition will be used for your code.
>
> as sqlite is only using pointer, and has his own definition, I do not see
> the problem.
>
> it breaks the ODR, but as I previously said it's used/allocated internally
> by sqlite which should never see your definition.
>
> can you explain in more detail what is happening ?
>
> can you make a small reproduceable sample ?
>
> also are you mixing C++ & C, or is your code all in c ?
>
> Daniel
>
> 2017-04-09 15:49 GMT-04:00 dip :
>
> > sqlite3.c is C file. C does not support namespaces.
> > Even though another project files are .cpp, sqlite3.c is still compiled
> as
> > C language source.
> > Therefore, no ability to use "using namespace" in sqlite3.c.
> > Also, "using namespace" does not actually put functions in the source in
> > namespace. It just helps it find another functions without specifying
> > namespace name.
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >
> >  Original Message 
> > Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes
> > having the same name
> > Local Time: April 9, 2017 10:23 PM
> > UTC Time: April 9, 2017 7:23 PM
> > From: d3c...@gmail.com
> > To: SQLite mailing list 
> >
> > On Sun, Apr 9, 2017 at 12:20 PM, Richard Damon  >
> > wrote:
> >
> > > On 4/9/17 1:49 PM, Olivier Mascia wrote:
> > >
> > >> Le 9 avr. 2017 à 18:49, dip  a écrit :
> > >>>
> > >>> I downloaded latest SQLite Amalgamation (v 3.18.0) to embed it in my
> > >>> project.
> > >>> After that I got a lot of errors while compiling (compiler is
> Microsoft
> > >>> Visual Studio 2017).
> > >>> Errors were caused by the following line in sqlite3.h:
> > >>>
> > >>> typedef struct Mem sqlite3_value;
> > >>>
> > >>> The reason is that I have the namespace with the same name.
> > >>> So I have a suggestion to rename "struct Mem" to something else (add
> > >>> prefix to it) because "Mem" is a very common name like "input" or
> > "data" or
> > >>> "buffer" and there may be classes or namespaces having the same name.
> > >>>
> > >> The way to overcome this completely in large programmings using many
> > >> libraries is to include sqlite3.h within a namespace. Not something
> that
> > >> SQLite code must do itself: that's best handled at the user project
> > level.
> > >>
> > >> The problem with this is that if the header file is put in a namespace
> > in
> > > the user code, then the source file that defines these functions needs
> to
> > > also be changed to put the files in that same namespace, or the things
> > > being defined won't be found.
> > >
> > > think that's what 'use namespace' is for
> >
> > > --
> > > Richard Damon
> > >
> > >
> > > ___
> > > sqlite-users mailing list
> > > sqlite-users@mailinglists.sqlite.org
> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
>
> --
> Daniel
> *L'action accède à la perfection quand, bien que vivant, vous êtes déjà
> mort*
> *Bunan*
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[dip]

I am mixing C and C++ code. My code is in C++, SQLite is in C.
Just create memory.h:

namespace Mem {
// some functions
}

And create code.cpp:

#include "memory.h"
#include "sqlite3.h"

void Func()
{
Mem::SomeFunc(); // gives the compilation error
}

Sent with [ProtonMail](https://protonmail.com) Secure Email.

 Original Message 
Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the 
same name
Local Time: April 10, 2017 2:29 AM
UTC Time: April 9, 2017 11:29 PM
From: woni...@gmail.com
To: SQLite mailing list 

I see no problems with C++.

Mem is only foward declared, you can redefined it to whatever you want. as
long as you do not redefined it for sqlite.c you should be good.

in sqlite.h it's declared:

struct Mem;

so in your code if you do:

struct Mem { int a;int b;} then your definition will be used for your code.

as sqlite is only using pointer, and has his own definition, I do not see
the problem.

it breaks the ODR, but as I previously said it's used/allocated internally
by sqlite which should never see your definition.

can you explain in more detail what is happening ?

can you make a small reproduceable sample ?

also are you mixing C++ & C, or is your code all in c ?

Daniel

2017-04-09 15:49 GMT-04:00 dip :

> sqlite3.c is C file. C does not support namespaces.
> Even though another project files are .cpp, sqlite3.c is still compiled as
> C language source.
> Therefore, no ability to use "using namespace" in sqlite3.c.
> Also, "using namespace" does not actually put functions in the source in
> namespace. It just helps it find another functions without specifying
> namespace name.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>  Original Message 
> Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes
> having the same name
> Local Time: April 9, 2017 10:23 PM
> UTC Time: April 9, 2017 7:23 PM
> From: d3c...@gmail.com
> To: SQLite mailing list 
>
> On Sun, Apr 9, 2017 at 12:20 PM, Richard Damon 
> wrote:
>
> > On 4/9/17 1:49 PM, Olivier Mascia wrote:
> >
> >> Le 9 avr. 2017 à 18:49, dip  a écrit :
> >>>
> >>> I downloaded latest SQLite Amalgamation (v 3.18.0) to embed it in my
> >>> project.
> >>> After that I got a lot of errors while compiling (compiler is Microsoft
> >>> Visual Studio 2017).
> >>> Errors were caused by the following line in sqlite3.h:
> >>>
> >>> typedef struct Mem sqlite3_value;
> >>>
> >>> The reason is that I have the namespace with the same name.
> >>> So I have a suggestion to rename "struct Mem" to something else (add
> >>> prefix to it) because "Mem" is a very common name like "input" or
> "data" or
> >>> "buffer" and there may be classes or namespaces having the same name.
> >>>
> >> The way to overcome this completely in large programmings using many
> >> libraries is to include sqlite3.h within a namespace. Not something that
> >> SQLite code must do itself: that's best handled at the user project
> level.
> >>
> >> The problem with this is that if the header file is put in a namespace
> in
> > the user code, then the source file that defines these functions needs to
> > also be changed to put the files in that same namespace, or the things
> > being defined won't be found.
> >
> > think that's what 'use namespace' is for
>
> > --
> > Richard Damon
> >
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

--
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users