Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection
Maybe adding "order by rowid" to your select statement can help avoid "sawing off the branch you are sitting on". Unless you need to update rowids... -Ursprüngliche Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Jens Alfke Gesendet: Dienstag, 31. Jänner 2017 04:30 An: SQLite mailing list Betreff: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection I’ve just run headlong in to the issues described in "No Isolation Between Operations On The Same Database Connection”. Specifically, I’ve discovered (after some debugging) that if I iterate over the the rows in a table using sqlite3_step, and update each row after it’s returned, Bad Stuff happens. Specifically, my query is just getting the first row over and over and over again, and the iteration runs forever. :( I had been under the impression that, since I’m using the WAL, queries operate on a snapshot of the database as of the time they begin, and are unaffected by subsequent changes. I got this from reading about "snapshot isolation” in a previous section of that document. (Also, another key/value database engine I’ve used recently _does_ behave this way, so it’s what I was expecting.) I now see that the “read transaction” described in that section has to be occurring in a different connection than the write transaction. (Right?) I’m unsure what to do now. I am working on a library whose API exposes iterator objects that run queries; the iterator’s “next()” method internally calls sqlite3_step. Thus the interleaving of the query and updating the database is not under my control; it’s up to the developer using our library, and I do _not_ want to expose inconvenient undefined behavior like this, or tell developers that “you can’t modify the database while you’re iterating it”. I can’t be the first person to run into this. Is there a best practice for enabling concurrent iteration and mutation? I can think of two solutions: A. Batch up all of the query results in memory at the start of the iteration, and have the iterator just read them out of the in-memory list. I’d like to avoid this because of the obvious memory overhead and latency imposed on large queries. Version 1 of our library worked this way, which is why I probably hadn’t noticed the problem until now. B. Create a separate SQLite connection for the query; then it’ll be isolated from any changes being made in the main connection. This seems elegant, but it will of course use more memory for the extra connection (with its own cache.) Moreover, it seems like I’ll need to open an indefinite number of extra connections: if the caller starts a query, makes some changes, and then starts another query (before reading the final row of the first query), I need to open another connection for the second query because it has to see the changes, which aren’t yet visible in the first query's connection … right? —Jens [1]: https://www.sqlite.org/isolation.html ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: h...@scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection
On 31 Jan 2017, at 5:26am, Jens Alfke wrote: > I don’t follow. What’s the “resource” you’re talking about here? In your case, the NSEnumerator . Would the solution I proposed in my post work for you ? Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection
> On Jan 30, 2017, at 9:10 PM, Simon Slavin wrote: > > Nope. Cannot do that. Any number of things might happen between the first > _step() and the _finalize(). For all you know someone might delete the > object the iterator is currently on instead of just updating it. Then where > would the iterator be ? As I explained, my assumption was that the iteration operated on a snapshot of the database at the time it was started, i.e. at the first call to sqlite3_step. There are other databases that operate that way, although I now understand SQLite doesn’t. I understand the situation. And I outlined two ways around the problem. So this isn’t a blanket “Cannot do that” situation, unless you’re saying I can’t do it the way I’ve been dong it … but I already know that! That’s why I posted my question. Reiterating it doesn’t help. > How would you know to release the resource ? And once you knew it, how would > you do it ? I don’t follow. What’s the “resource” you’re talking about here? —Jens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection
> On Jan 30, 2017, at 8:03 PM, Rowan Worth wrote: > > If the iterator isn't exhausted, how do you know when to dispose the > sqlite3_stmt? The iterator (which is an Objective-C NSEnumerator object) will be deleted shortly after it exits scope. Some of the refcounting is deferred via the autorelease pool, but basically by the time the thread returns back to its event loop. —Jens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection
On 31 Jan 2017, at 3:29am, Jens Alfke wrote: > I’ve discovered (after some debugging) that if I iterate over the the rows in > a table using sqlite3_step, and update each row after it’s returned, Bad > Stuff happens. Specifically, my query is just getting the first row over and > over and over again, and the iteration runs forever Is your UPDATE command changing a value which is used for the SELECT ? If so, what you reported is expected behaviour. If you’re expecting to execute two statements at the same time you should be using two connections. > I’m unsure what to do now. I am working on a library whose API exposes > iterator objects that run queries; the iterator’s “next()” method internally > calls sqlite3_step. Nope. Cannot do that. Any number of things might happen between the first _step() and the _finalize(). For all you know someone might delete the object the iterator is currently on instead of just updating it. Then where would the iterator be ? How would you know to release the resource ? And once you knew it, how would you do it ? One solution is to make each call to .next() do its own SELECT. So if, for example, it was acceptable to iterate the rows in rowid order then calling .next() would do SELECT rowid FROM MyTable WHERE rowid > [current rowid] ORDER BY rowid LIMIT 1 If this gives a row, that’s your next object. If it doesn’t, you’ve reached the end. Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the same connection
The iterator pattern has another caveat when applied to sqlite:
foreach (row in statement) {
if (isMatch(row)) {
return true
}
}
return false
If the iterator isn't exhausted, how do you know when to dispose the
sqlite3_stmt? There are other ways to manage the statement's lifetime so
this isn't a deal breaker, just something to keep in mind.
I know that our code base uses step/UPDATE/step/UPDATE/... in a couple of
places, without problems. But I guess that is just luck; as you note the
documentation clearly says the behaviour is undefined. To repeatedly get
the _same_ row over and over seems incredibly unfortunate though!
-Rowan
On 31 January 2017 at 11:29, Jens Alfke wrote:
> I’ve just run headlong in to the issues described in "No Isolation Between
> Operations On The Same Database Connection”. Specifically, I’ve discovered
> (after some debugging) that if I iterate over the the rows in a table using
> sqlite3_step, and update each row after it’s returned, Bad Stuff happens.
> Specifically, my query is just getting the first row over and over and over
> again, and the iteration runs forever. :(
>
> I had been under the impression that, since I’m using the WAL, queries
> operate on a snapshot of the database as of the time they begin, and are
> unaffected by subsequent changes. I got this from reading about "snapshot
> isolation” in a previous section of that document. (Also, another key/value
> database engine I’ve used recently _does_ behave this way, so it’s what I
> was expecting.) I now see that the “read transaction” described in that
> section has to be occurring in a different connection than the write
> transaction. (Right?)
>
> I’m unsure what to do now. I am working on a library whose API exposes
> iterator objects that run queries; the iterator’s “next()” method
> internally calls sqlite3_step. Thus the interleaving of the query and
> updating the database is not under my control; it’s up to the developer
> using our library, and I do _not_ want to expose inconvenient undefined
> behavior like this, or tell developers that “you can’t modify the database
> while you’re iterating it”.
>
> I can’t be the first person to run into this. Is there a best practice for
> enabling concurrent iteration and mutation? I can think of two solutions:
>
> A. Batch up all of the query results in memory at the start of the
> iteration, and have the iterator just read them out of the in-memory list.
> I’d like to avoid this because of the obvious memory overhead and
> latency imposed on large queries. Version 1 of our library worked this way,
> which is why I probably hadn’t noticed the problem until now.
>
> B. Create a separate SQLite connection for the query; then it’ll be
> isolated from any changes being made in the main connection.
> This seems elegant, but it will of course use more memory for the
> extra connection (with its own cache.) Moreover, it seems like I’ll need to
> open an indefinite number of extra connections: if the caller starts a
> query, makes some changes, and then starts another query (before reading
> the final row of the first query), I need to open another connection for
> the second query because it has to see the changes, which aren’t yet
> visible in the first query's connection … right?
>
> —Jens
>
> [1]: https://www.sqlite.org/isolation.html
> ___
> 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] Bitten by lack of isolation between SELECT and UPDATE on the same connection
I’ve just run headlong in to the issues described in "No Isolation Between Operations On The Same Database Connection”. Specifically, I’ve discovered (after some debugging) that if I iterate over the the rows in a table using sqlite3_step, and update each row after it’s returned, Bad Stuff happens. Specifically, my query is just getting the first row over and over and over again, and the iteration runs forever. :( I had been under the impression that, since I’m using the WAL, queries operate on a snapshot of the database as of the time they begin, and are unaffected by subsequent changes. I got this from reading about "snapshot isolation” in a previous section of that document. (Also, another key/value database engine I’ve used recently _does_ behave this way, so it’s what I was expecting.) I now see that the “read transaction” described in that section has to be occurring in a different connection than the write transaction. (Right?) I’m unsure what to do now. I am working on a library whose API exposes iterator objects that run queries; the iterator’s “next()” method internally calls sqlite3_step. Thus the interleaving of the query and updating the database is not under my control; it’s up to the developer using our library, and I do _not_ want to expose inconvenient undefined behavior like this, or tell developers that “you can’t modify the database while you’re iterating it”. I can’t be the first person to run into this. Is there a best practice for enabling concurrent iteration and mutation? I can think of two solutions: A. Batch up all of the query results in memory at the start of the iteration, and have the iterator just read them out of the in-memory list. I’d like to avoid this because of the obvious memory overhead and latency imposed on large queries. Version 1 of our library worked this way, which is why I probably hadn’t noticed the problem until now. B. Create a separate SQLite connection for the query; then it’ll be isolated from any changes being made in the main connection. This seems elegant, but it will of course use more memory for the extra connection (with its own cache.) Moreover, it seems like I’ll need to open an indefinite number of extra connections: if the caller starts a query, makes some changes, and then starts another query (before reading the final row of the first query), I need to open another connection for the second query because it has to see the changes, which aren’t yet visible in the first query's connection … right? —Jens [1]: https://www.sqlite.org/isolation.html ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit
It's an iBook, so some version of OS X I would guess. From a little searching online, 10.2 was the last release in 2002, and it seems that it may have included GCC 3.3. GCC 3.3 did not fully support C99 (as its release notes indicated "A few more ISO C99 features now work correctly." Of course, things could have been upgraded in which case this is all moot. I appreciate the desire to be using as modern of a toolset as possible. Basing source on "ANSI C" (as much as possible) just gives you the biggest possible distribution / compatibility. Not that you can just ignore other issues, of course, but given that a fix for this issue has already been committed, and allows the code to work with both C89 & C99, the original report is no longer a consideration. On Mon, Jan 30, 2017 at 12:08 PM, James K. Lowden wrote: > > On Sun, 29 Jan 2017 21:40:23 -0500 > Richard Hipp wrote: > > > On 1/29/17, James K. Lowden wrote: > > > > > > I wonder what pricey embedded environment both supports dlopen(2) > > > and does not support C99, in this day and age. > > > > One of the test platforms for SQLite is an old iBook I bought back in > > approximately 2002. Dunno if it support C99 or not, but I suspect > > not, as there is quite a bit it does not support. > > What compiler and OS are you using? The pcc and gcc compilers both > support C99 on the PPC architecture. > > > This is a important test platform because it uses a PPC CPU, which > > means it is big-endian and thus serves to verify that SQLite works on > > both big-endian and little-ending machines and that the database files > > are freely interchangeable. > > I am glad you do this. I used to do the same for FreeTDS using > Sparcstation. > > If you are interested in upgrading the SQLite core to C99, I'm > willing to do the legwork and can supply the needed paperwork. I know > we can find a compiler for your PPC machine, and I bet if need be we can > port pcc to whatever you're running. (ISTM enlisting pcc would add to > SQLite's portability, btw.) > > --jkl > > > ___ > 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
Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit
On Sun, 29 Jan 2017 21:40:23 -0500 Richard Hipp wrote: > On 1/29/17, James K. Lowden wrote: > > > > I wonder what pricey embedded environment both supports dlopen(2) > > and does not support C99, in this day and age. > > One of the test platforms for SQLite is an old iBook I bought back in > approximately 2002. Dunno if it support C99 or not, but I suspect > not, as there is quite a bit it does not support. What compiler and OS are you using? The pcc and gcc compilers both support C99 on the PPC architecture. > This is a important test platform because it uses a PPC CPU, which > means it is big-endian and thus serves to verify that SQLite works on > both big-endian and little-ending machines and that the database files > are freely interchangeable. I am glad you do this. I used to do the same for FreeTDS using Sparcstation. If you are interested in upgrading the SQLite core to C99, I'm willing to do the legwork and can supply the needed paperwork. I know we can find a compiler for your PPC machine, and I bet if need be we can port pcc to whatever you're running. (ISTM enlisting pcc would add to SQLite's portability, btw.) --jkl ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Slight incompatibility of v. 3.16.2 from previousreleases (compiler error)
> Mensaje original > De: Dan Kennedy > Para: sqlite-users@mailinglists.sqlite.org > > On 01/30/2017 05:39 PM, a...@zator.com wrote: >> Hi list: >> >> Building with SQLite v. 3.16.2 and MS VC++ 2015 (v 14.0) there appeared a >> linker error: >> >> Error LNK2019 external simbol _sqlite3FkReferences unresolved in function >> _sqlite3Insert >> >> Who belong (I suppose) to a compiler warning: >> >> line 109039: warning C4013: 'sqlite3FkReferences' undefined >> >> I use the following configh, who compiles Ok with v. 3.9.1 and earlier. >> >> #define SQLITE_MAX_VARIABLE_NUMBER 25 >> #define SQLITE_DEFAULT_PAGE_SIZE 1024 >> #define SQLITE_THREADSAFE 1 >> #define SQLITE_OMIT_PROGRESS_CALLBACK 1 >> #define SQLITE_OMIT_FOREIGN_KEY 1 >> #define SQLITE_OMIT_AUTOVACUUM 1 >> #define SQLITE_OMIT_EXPLAIN 1 >> #define SQLITE_SECURE_DELETE 1 >> #define SQLITE_OMIT_BUILTIN_TEST 1 >> #define SQLITE_OMIT_TRACE 1 >> #define SQLITE_ENABLE_FTS5 1 >> >> Any clue of how surpass with a minimal distortion in the config file would >> be appreciated. > >Removing the "SQLITE_OMIT_FOREIGN_KEY" line would probably fix things. > >Or grab the one-line patch from here: > > http://www.sqlite.org/src/info/e93d2c49a44af994 > >Dan. Thanks a lot. Both solutions works as expected. -- Adolfo J. Millan Zator Systems. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] can't open db when path length extends 512 characters (on linux)
On 01/31/2017 12:48 AM, Nir Paz wrote: Hi All, I get the next error: SQLITE_CANTOPEN when calling sqlite3_open_v2 with filename exceeding 512 characters. Linux doesn't have that limit, my thought is to change the define of MAX_PATHNAME, is there a better option? I don't think there is a better way to do that. Define MAX_PATHNAME to something and see how it goes. There is one very subtle problem that we know of: http://www.sqlite.org/src/artifact/ff1232b3088a3?ln=2771-2775 This means that if database page size is smaller in bytes than the filenames, you might find that following recovery from a crash or power failure occurs during COMMIT of a multi-file transaction in rollback mode a some of the databases written to have committed and some rolled back the transaction. As can happen in wal mode. Dan. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] can't open db when path length extends 512 characters (on linux)
Hi All, I get the next error: SQLITE_CANTOPEN when calling sqlite3_open_v2 with filename exceeding 512 characters. Linux doesn't have that limit, my thought is to change the define of MAX_PATHNAME, is there a better option? Thanks, Nir ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Hick Gunter
>>>Integer promotion is usually ok between integers of the same signedness.
For some definition of 'OK'.
>>>However, in
unsigned char uns = 0xff;
long val = uns;
>>>what should be the (32 Bit size assumed) value of val? Should it be
>>>0x00ff (promotion before conversion) or 0x (promotion after
>>>conversion)? Or flagged as "assignment between variables of different
>>>signedness"?
The standard is clear about this case (as it is about nearly all cases). Value
is always preserved in integer promotion if possible. The value is simply 255
in any integer large enough to hold it.
>>>Or for example, how often is the loop executed?
uint16_t count = 0x;
int16_t ii;
for (ii = 0; II < count, ii++) { ... }
>>> Integer demotion (i.e. copying a value from a larger size to a smaller size
>>> integer) should be flagged by the compiler (unless the compiler is clever
>>> enough to figure out that the value cannot be out of range).
The standard does not define 'demotion'. This loop will not terminate because
incrementing the loop variable will cause integer overflow (usually ignored)
and the test will always be true. The conversions for the test preserve value.
>>>long val = 0x65;
char xxx = val;
Valid C, but typically causes a warning.
>>>However
struct mystruct *ptr1 = '\0';
struct mystruct *ptr2 = 0;
>>>is "making a pointer from an integer of a different size without a cast"
>>>(the first on all architectures, the second on LP64 architectures).
I have no idea what you intend by this, but this too is valid C. No warnings.
>>>Of course this is nitpicking and the examples are trivial, but compilers
>>>need to guess if the programmer is just being stupid or downright
>>>brilliant...
I'm still waiting for the nits. The C/C++ standards are written precisely to
cover these and other things that those maintaining mature source code really
care about.
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
___
Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: h...@scigames.at
This communication (including any attachments) is intended for the use of the
intended recipient(s) only and may contain information that is confidential,
privileged or legally protected. Any unauthorized use or dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please immediately notify the sender by return e-mail message and
delete all copies of the original communication. Thank you for your cooperation.
___
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
Re: [sqlite] Slight incompatibility of v. 3.16.2 from previous releases (compiler error)
On 01/30/2017 05:39 PM, a...@zator.com wrote: Hi list: Building with SQLite v. 3.16.2 and MS VC++ 2015 (v 14.0) there appeared a linker error: Error LNK2019 external simbol _sqlite3FkReferences unresolved in function _sqlite3Insert Who belong (I suppose) to a compiler warning: line 109039: warning C4013: 'sqlite3FkReferences' undefined I use the following config.h, who compiles Ok with v. 3.9.1 and earlier. #define ZENABLE_FTS5 #define SQLITE_MAX_VARIABLE_NUMBER 25 #define SQLITE_DEFAULT_PAGE_SIZE 1024 #define SQLITE_THREADSAFE 1 #define SQLITE_OMIT_PROGRESS_CALLBACK 1 #define SQLITE_OMIT_FOREIGN_KEY 1 #define SQLITE_OMIT_AUTOVACUUM 1 #define SQLITE_OMIT_EXPLAIN 1 #define SQLITE_SECURE_DELETE 1 #define SQLITE_OMIT_BUILTIN_TEST 1 #define SQLITE_OMIT_TRACE 1 #define SQLITE_ENABLE_FTS5 1 Any clue of how surpass with a minimal distortion in the config file would be appreciated. Removing the "SQLITE_OMIT_FOREIGN_KEY" line would probably fix things. Or grab the one-line patch from here: http://www.sqlite.org/src/info/e93d2c49a44af994 Dan. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Slight incompatibility of v. 3.16.2 from previous releases (compiler error)
Hi list: Building with SQLite v. 3.16.2 and MS VC++ 2015 (v 14.0) there appeared a linker error: Error LNK2019 external simbol _sqlite3FkReferences unresolved in function _sqlite3Insert Who belong (I suppose) to a compiler warning: line 109039: warning C4013: 'sqlite3FkReferences' undefined I use the following config.h, who compiles Ok with v. 3.9.1 and earlier. #define ZENABLE_FTS5 #define SQLITE_MAX_VARIABLE_NUMBER 25 #define SQLITE_DEFAULT_PAGE_SIZE 1024 #define SQLITE_THREADSAFE 1 #define SQLITE_OMIT_PROGRESS_CALLBACK 1 #define SQLITE_OMIT_FOREIGN_KEY 1 #define SQLITE_OMIT_AUTOVACUUM 1 #define SQLITE_OMIT_EXPLAIN 1 #define SQLITE_SECURE_DELETE 1 #define SQLITE_OMIT_BUILTIN_TEST 1 #define SQLITE_OMIT_TRACE 1 #define SQLITE_ENABLE_FTS5 1 Any clue of how surpass with a minimal distortion in the config file would be appreciated. -- Adolfo J. Millán Zator Systems ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit
>-Ursprüngliche Nachricht-
>Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
>Auftrag von James K. Lowden
>Gesendet: Freitag, 27. Jänner 2017 20:08
>An: sqlite-users@mailinglists.sqlite.org
>Betreff: Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit
>
>On Thu, 26 Jan 2017 08:19:02 +
>Hick Gunter wrote:
>
>> On LP_64 architactures, the integer 0 is 32 bits while (void *)0 is
>> 64 bits, which makes more than a bit of a difference. A 64 bit integer
>> 0 would be denoted by 0L.
>
>in C, as you know, integer assignment is subject to integer promotion.
>If the LHS is wider, the RHS is widened to match. The specification is much
>more precise, of course, but that's the effect.
>
>There's nothing invalid of ambiguous about:
>
> long L = '\0';
>
>It is the same as
>
> long L = 0L;
>
>The same is true for pointers.
>
>--jkl
>
Integer promotion is usually ok between integers of the same signedness.
However, in
unsigned char uns = 0xff;
long val = uns;
what should be the (32 Bit size assumed) value of val? Should it be 0x00ff
(promotion before conversion) or 0x (promotion after conversion)? Or
flagged as "assignment between variables of different signedness"?
Or for example, how often is the loop executed?
uint16_t count = 0x;
int16_t ii;
for (ii = 0; II < count, ii++) { ... }
Integer demotion (i.e. copying a value from a larger size to a smaller size
integer) should be flagged by the compiler (unless the compiler is clever
enough to figure out that the value cannot be out of range).
long val = 0x65;
char xxx = val;
However
struct mystruct *ptr1 = '\0';
struct mystruct *ptr2 = 0;
is "making a pointer from an integer of a different size without a cast" (the
first on all architectures, the second on LP64 architectures).
Of course this is nitpicking and the examples are trivial, but compilers need
to guess if the programmer is just being stupid or downright brilliant...
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: h...@scigames.at
This communication (including any attachments) is intended for the use of the
intended recipient(s) only and may contain information that is confidential,
privileged or legally protected. Any unauthorized use or dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please immediately notify the sender by return e-mail message and
delete all copies of the original communication. Thank you for your cooperation.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
