Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
Thanks for the patch! Tests on i686 are green when included. There are still some failures for other architectures but I will make separate threads for these once I investigate. Petr On 01/23/2018 06:35 PM, Richard Hipp wrote: On 1/23/18, Petr Kubat wrote: Still present in 3.22.0: ! e_expr-32.2.5 expected: [integer 9223372036854775807] ! e_expr-32.2.5 got: [real 9.22337203685478e+18] Is there any more information I can provide to get this looked at? Ralf provided the information I needed, which was a method of reproducing the problem. It is now fixed on trunk. See https://www.sqlite.org/src/info/1b02731962c21bb0 for the patch. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
If it helps, I can reproduce with the mentioned binary on Win7 but I cannot with my own compiled version (using MSVC). -Original Message- From: Ralf Junker On 23.01.2018 15:31, Richard Hipp wrote: I'm still unable to reproduce this problem. sqlite3.exe from this ZIP: https://www.sqlite.org/2018/sqlite-tools-win32-x86-322.zip Running on Windows 7: SQLite version 3.22.0 2018-01-22 18:45:57 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9.22337203685478e+18 sqlite> SELECT CAST ('9223372036854775807' AS NUMERIC); 9223372036854775807 Notice the trailing white space which makes the difference. Ralf ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
On 1/23/18, Petr Kubat wrote: > Still present in 3.22.0: > > ! e_expr-32.2.5 expected: [integer 9223372036854775807] > ! e_expr-32.2.5 got: [real 9.22337203685478e+18] > > Is there any more information I can provide to get this looked at? Ralf provided the information I needed, which was a method of reproducing the problem. It is now fixed on trunk. See https://www.sqlite.org/src/info/1b02731962c21bb0 for the patch. -- 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] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
What locale? The locale setting may influence character to numeric conversions at the C language library level. sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); > 9.22337203685478e+18 > sqlite> SELECT CAST ('9223372036854775807' AS NUMERIC); > 9223372036854775807 > Notice the trailing white space which makes the difference. Although U.S. dollar users are used to the currency symbol to the left of the digits; in some countries the currency symbol is to the right of the digits and sometimes there is a space between the digits and the currency symbol. Currencies are often represented as decimals (except when accounting systems use integer pennies) and so a trailing space in some or all locales may trigger an assumption of either a monetary or floating point value. The locale could impact something as low level as an atoi() or atol() C conversion functions. https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rtref/itol.htm#itol "These members are 1 if the currency_symbol or int_curr_symbol strings should precede the value of a monetary amount, or 0 if the strings should follow the value. The p_cs_precedes and int_p_cs_precedes members apply to positive amounts (or zero), and the n_cs_precedes and int_n_cs_precedes members apply to negative amounts." ... "These members are 1 if a space should appear between the currency_symbol or int_curr_symbol strings and the amount, or 0 if no space should appear. The p_sep_by_space and int_p_sep_by_space members apply to positive amounts (or zero), and the n_sep_by_space and int_n_sep_by_space members apply to negative amounts." https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Currency-Symbol.html#Currency-Symbol "In many European countries such as France, Germany, Greece, Scandinavian countries, the symbol is usually placed after the amount (e.g., 20,50 €)." Note space between amount and Euro symbol. https://en.wikipedia.org/wiki/Currency_symbol Scientific Linux is used at CERN and ETHZ and other European facilities? So, my guess would be that the space after the number, plus certain locales would reproduce the issue. Jim Callahan Callahan Data Science LLC Orlando, FL On Tue, Jan 23, 2018 at 10:22 AM, Ralf Junker wrote: > On 23.01.2018 15:31, Richard Hipp wrote: > > I'm still unable to reproduce this problem. >> > > sqlite3.exe from this ZIP: > > https://www.sqlite.org/2018/sqlite-tools-win32-x86-322.zip > > Running on Windows 7: > > SQLite version 3.22.0 2018-01-22 18:45:57 > Enter ".help" for usage hints. > Connected to a transient in-memory database. > Use ".open FILENAME" to reopen on a persistent database. > sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); > 9.22337203685478e+18 > sqlite> SELECT CAST ('9223372036854775807' AS NUMERIC); > 9223372036854775807 > > Notice the trailing white space which makes the difference. > > Ralf > > ___ > 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] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
On 23.01.2018 15:31, Richard Hipp wrote: I'm still unable to reproduce this problem. sqlite3.exe from this ZIP: https://www.sqlite.org/2018/sqlite-tools-win32-x86-322.zip Running on Windows 7: SQLite version 3.22.0 2018-01-22 18:45:57 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9.22337203685478e+18 sqlite> SELECT CAST ('9223372036854775807' AS NUMERIC); 9223372036854775807 Notice the trailing white space which makes the difference. Ralf ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
On Jan 23, 2018 9:32 AM, "Richard Hipp" wrote: I'm still unable to reproduce this problem. I've tried on every 32-bit platform I have at hand: * Ubuntu with -m32 * Android * MacOS 10.6.8 with -m32 * MinGW (32-bit) on Win7 * MSVC (32-bit) on Win10 They all give the correct answer. I'm sorry you are having problems. But it is difficult for me to fix the problem if I am unable to reproduce it. Is it possible Mr. Lee or Mr. Kubat could provide a guest login to Dr. Hipp on a system exhibiting this problem, so that he might be able to investigate it on a system known to be having the problem? Joseph ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
I'm still unable to reproduce this problem. I've tried on every 32-bit platform I have at hand: * Ubuntu with -m32 * Android * MacOS 10.6.8 with -m32 * MinGW (32-bit) on Win7 * MSVC (32-bit) on Win10 They all give the correct answer. I'm sorry you are having problems. But it is difficult for me to fix the problem if I am unable to reproduce it. On 1/23/18, Petr Kubat wrote: > Still present in 3.22.0: > > ! e_expr-32.2.5 expected: [integer 9223372036854775807] > ! e_expr-32.2.5 got: [real 9.22337203685478e+18] > ! e_expr-32.2.6 expected: [integer 9223372036854775807] > ! e_expr-32.2.6 got: [real 9.22337203685478e+18] > ! e_expr-32.2.8 expected: [integer 901 integer > 901 integer 901 integer 901 > integer 901 integer 901 integer > 9223372036854775807 integer 9223372036854775807 integer 9223372036854775807 > real 9.22337203685478e+18 real 9.22337203685478e+18 integer > 9223372036854775807 integer 9223372036854775807 integer -5 integer -5] > ! e_expr-32.2.8 got: [integer 901 real 9.0e+18 real > 9.0e+18 real 9.0e+18 integer 901 real 9.0e+18 integer > 9223372036854775807 real 9.22337203685478e+18 real 9.22337203685478e+18 real > 9.22337203685478e+18 real 9.22337203685478e+18 real 9.22337203685478e+18 > real 9.22337203685478e+18 integer -5 integer -5] > > This seems to be happening whenever a string not ending with a number > ('901x', '901 ',' 901.') > gets cast to NUMERIC. > > Is there any more information I can provide to get this looked at? > > On 11/01/2017 01:07 PM, Petr Kubat wrote: >> Encountering this in Fedora as well while trying to package latest >> 3.21.0 version. Only on i386. >> >> Additionally the test suite fails on some architectures (aarch64, >> ppc64, s390x) when running the test case fts3expr5-1.5: >> >> ! fts3expr5-1.5 expected: [1 {invalid matchinfo blob passed to >> function rank()}] >> ! fts3expr5-1.5 got: [1 {wrong number of arguments to function >> rank()}] >> >> >> On 10/28/2017 12:43 AM, Timothy J. Lee wrote: >>> sqlite 3.21.0, built from source on Scientific Linux 6 >>> (which is derived from Red Hat Enterprise Linux 6). >>> >>> configure options were: >>> --enable-threadsafe --enable-threads-override-locks >>> --enable-load-extension >>> >>> CFLAGS="-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1 >>> -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 >>> -DSQLITE_SECURE_DELETE=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -Wall >>> -fno-strict-aliasing" >>> >>> On i386: >>> >>> sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); >>> 9.22337203685478e+18 >>> sqlite> >>> >>> On x86_64: >>> >>> sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); >>> 9223372036854775807 >>> sqlite> >>> >>> This difference causes self-tests e_expr-32.2.5 e_expr-32.2.6 >>> e_expr-32.2.8 >>> to fail on i386 (the output on x86_64 is the expected output). >>> ___ >>> 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 > -- 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] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
Still present in 3.22.0: ! e_expr-32.2.5 expected: [integer 9223372036854775807] ! e_expr-32.2.5 got: [real 9.22337203685478e+18] ! e_expr-32.2.6 expected: [integer 9223372036854775807] ! e_expr-32.2.6 got: [real 9.22337203685478e+18] ! e_expr-32.2.8 expected: [integer 901 integer 901 integer 901 integer 901 integer 901 integer 901 integer 9223372036854775807 integer 9223372036854775807 integer 9223372036854775807 real 9.22337203685478e+18 real 9.22337203685478e+18 integer 9223372036854775807 integer 9223372036854775807 integer -5 integer -5] ! e_expr-32.2.8 got: [integer 901 real 9.0e+18 real 9.0e+18 real 9.0e+18 integer 901 real 9.0e+18 integer 9223372036854775807 real 9.22337203685478e+18 real 9.22337203685478e+18 real 9.22337203685478e+18 real 9.22337203685478e+18 real 9.22337203685478e+18 real 9.22337203685478e+18 integer -5 integer -5] This seems to be happening whenever a string not ending with a number ('901x', '901 ',' 901.') gets cast to NUMERIC. Is there any more information I can provide to get this looked at? On 11/01/2017 01:07 PM, Petr Kubat wrote: Encountering this in Fedora as well while trying to package latest 3.21.0 version. Only on i386. Additionally the test suite fails on some architectures (aarch64, ppc64, s390x) when running the test case fts3expr5-1.5: ! fts3expr5-1.5 expected: [1 {invalid matchinfo blob passed to function rank()}] ! fts3expr5-1.5 got: [1 {wrong number of arguments to function rank()}] On 10/28/2017 12:43 AM, Timothy J. Lee wrote: sqlite 3.21.0, built from source on Scientific Linux 6 (which is derived from Red Hat Enterprise Linux 6). configure options were: --enable-threadsafe --enable-threads-override-locks --enable-load-extension CFLAGS="-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_SECURE_DELETE=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -Wall -fno-strict-aliasing" On i386: sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9.22337203685478e+18 sqlite> On x86_64: sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9223372036854775807 sqlite> This difference causes self-tests e_expr-32.2.5 e_expr-32.2.6 e_expr-32.2.8 to fail on i386 (the output on x86_64 is the expected output). ___ 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
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
Encountering this in Fedora as well while trying to package latest 3.21.0 version. Only on i386. Additionally the test suite fails on some architectures (aarch64, ppc64, s390x) when running the test case fts3expr5-1.5: ! fts3expr5-1.5 expected: [1 {invalid matchinfo blob passed to function rank()}] ! fts3expr5-1.5 got: [1 {wrong number of arguments to function rank()}] On 10/28/2017 12:43 AM, Timothy J. Lee wrote: sqlite 3.21.0, built from source on Scientific Linux 6 (which is derived from Red Hat Enterprise Linux 6). configure options were: --enable-threadsafe --enable-threads-override-locks --enable-load-extension CFLAGS="-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_SECURE_DELETE=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -Wall -fno-strict-aliasing" On i386: sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9.22337203685478e+18 sqlite> On x86_64: sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9223372036854775807 sqlite> This difference causes self-tests e_expr-32.2.5 e_expr-32.2.6 e_expr-32.2.8 to fail on i386 (the output on x86_64 is the expected output). ___ 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] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
sqlite 3.21.0, built from source on Scientific Linux 6 (which is derived from Red Hat Enterprise Linux 6). configure options were: --enable-threadsafe --enable-threads-override-locks --enable-load-extension CFLAGS="-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_SECURE_DELETE=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -Wall -fno-strict-aliasing" On i386: sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9.22337203685478e+18 sqlite> On x86_64: sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC); 9223372036854775807 sqlite> This difference causes self-tests e_expr-32.2.5 e_expr-32.2.6 e_expr-32.2.8 to fail on i386 (the output on x86_64 is the expected output). ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users