Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Simon Slavin]

On 3 Feb 2017, at 4:24pm, Warren Young  wrote:

> On Feb 3, 2017, at 9:15 AM, Simon Slavin  wrote:
> 
>> My solicitors will be in the post.
> 
> How much does it cost to mail a lawyer where you are?  Do they charge by 
> weight or unusual shape?

Oh, the solicitors pay the postage costs themselves.  But they then charge you 
their hourly rate for the five hours it takes them to do the associated 
paperwork.

Simon.
___
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

[Warren Young]

On Feb 3, 2017, at 9:15 AM, Simon Slavin  wrote:
> 
> My solicitors will be in the post.

How much does it cost to mail a lawyer where you are?  Do they charge by weight 
or unusual shape?
___
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

[Simon Slavin]

On 3 Feb 2017, at 2:35pm, James K. Lowden  wrote:

> When I was
> using Microsoft's C++ intensively, I would find a compiler bug about
> once a month.

A different set of bugs depending on the optimization level you were using.

Oh man, you brought it all back.  My solicitors will be in the post.

Simon.
___
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

[James K. Lowden]

On Wed, 01 Feb 2017 17:48:48 -0500
"Keith Medcalf"  wrote:

> Microsoft products require multiple versions of multiple Microsoft
> and third-party compilers to compile any of their products.  They
> will simply add whatever is needed to their internal compilers suite
> and use that to build the winsqlite.dll 

Interesting to know.  I was only suggesting the possibility that the
internal calculus at Microsoft might be affected by the number of lines
of C11 source they have to compile.  Surely there's some pocket of
modernity somewhere along Only One Microsoft Way.  

> The only issue I've run into using a Microsoft compiler is that it
> does not handle in-block initialization and declarations -- they all
> have to be at the top of a function before the first "executable"
> statement.  I believe that was a C language restriction back in the
> early 70's.

I'm pretty sure top of scope is OK, too.  You can declare variables as
the first statement inside any brace, afaik.  

You're fortunate that's the only issue you encountered.  When I was
using Microsoft's C++ intensively, I would find a compiler bug about
once a month.  Very often the solution was to use a typedef or
eliminate one.  (They're not alone.  On a current C project, GNU fell
down passing a struct parameter by value (not as a pointer).  The
received value was just garbled.  I'm not sure why, but it seems that
at a certain level of complexity every compiler ties its shoelaces
together.  

--jkl
___
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

[Scott Robison]

On Wed, Feb 1, 2017 at 3:48 PM, Keith Medcalf  wrote:

>
> > On Tue, 31 Jan 2017 15:50:08 -0800 James K. Lowden <
> jklow...@schemamania.org> wrote:
>
> > Last year there was much rejoicing when Microsoft decided to bundle
> > SQLite with Windows.  That leaves me with a new question: if SQLite
> > announced its intention to move to C11 in 2018, would that perhaps
> > influence Microsoft's timeline to update its compiler?
>
> No.  Microsoft products require multiple versions of multiple Microsoft
> and third-party compilers to compile any of their products.  They will
> simply add whatever is needed to their internal compilers suite and use
> that to build the winsqlite.dll for distribution with Windows.  Windows
> does not use ICU and does not support the use of timezones, etc, so there
> is no need for them to update their compilers at all as they will never use
> anything but the most primitive of any feature available.
>
> That said, there is no problem with Visual Studio compiling the ICU module
> as it was -- it works just fine without error.  Just that when set to
> pedantic mode it produces a higher level of messages, whether they be a
> true statement of fact or not.
>
> The only issue I've run into using a Microsoft compiler is that it does
> not handle in-block initialization and declarations -- they all have to be
> at the top of a function before the first "executable" statement.  I
> believe that was a C language restriction back in the early 70's.
>

The declaration of variables have to be at the top of a scope as per ANSI
C. C99 relaxed that.
-- 
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

[Keith Medcalf]

> On Tue, 31 Jan 2017 15:50:08 -0800 James K. Lowden  
> wrote:

> Last year there was much rejoicing when Microsoft decided to bundle
> SQLite with Windows.  That leaves me with a new question: if SQLite
> announced its intention to move to C11 in 2018, would that perhaps
> influence Microsoft's timeline to update its compiler?

No.  Microsoft products require multiple versions of multiple Microsoft and 
third-party compilers to compile any of their products.  They will simply add 
whatever is needed to their internal compilers suite and use that to build the 
winsqlite.dll for distribution with Windows.  Windows does not use ICU and does 
not support the use of timezones, etc, so there is no need for them to update 
their compilers at all as they will never use anything but the most primitive 
of any feature available.

That said, there is no problem with Visual Studio compiling the ICU module as 
it was -- it works just fine without error.  Just that when set to pedantic 
mode it produces a higher level of messages, whether they be a true statement 
of fact or not.

The only issue I've run into using a Microsoft compiler is that it does not 
handle in-block initialization and declarations -- they all have to be at the 
top of a function before the first "executable" statement.  I believe that was 
a C language restriction back in the early 70's.

Of course, Microsoft compilers are somewhat, shall we say, crappy, and the code 
generated is also of the same calibre.  Not to mention that there is neither 
forwards nor backwards runtime compatibility so you need to have just about 
every version of the compiler ever produced by Microsoft to do anything useful 
(which is not required with other compilers).




___
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

[dandl]

From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of James K. Lowden

>>>Despite the fact that the Windows API is defined in terms of C, Microsoft 
>>>evidently and probably correctly has decided its market does not demand a 
>>>modern C compiler.  

The Microsoft Windows API is defined very much in terms of C89. As an interface 
standard, I approve.

But you are correct. I haven't heard of anyone using C for new Windows 
development for many years, since C++ is almost essential for accessing any of 
the newer Microsoft technologies (eg COM, DirectX), and provides a vastly 
superior programming environment. 

We need to be clear about the difference between a piece of software than can 
be built on every possible kind of hardware and O/S, as against API standards 
and programming convenience on a specific platform. As I said previously, there 
are trade-offs.

>>>Last year there was much rejoicing when Microsoft decided to bundle SQLite 
>>>with Windows.  That leaves me with a new question: if SQLite announced its 
>>>intention to move to C11 in 2018, would that perhaps influence Microsoft's 
>>>timeline to update its compiler?  

Hypothetical question, won't happen, no it wouldn't.

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

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Scott Robison]

On Jan 31, 2017 6:25 PM, "James K. Lowden"  wrote:

On Tue, 31 Jan 2017 15:50:08 -0800
Nathan Bossett  wrote:

> Since this is the sqlite users list and not the dev's list, can I ask
> what your use case is that writing a thin wrapper around SQLITE
> doesn't solve your problem?

I've encountered no problem compiling SQLite header files as C11.

The OP encountered a problem compiling SQLite itself as C89 because
there was a C99 construct his compiler didn't support.  The fix was to
"update" the code to conform to a 17-year old standard.

I wondered aloud what system still exists that supports only C89.  On
review of this thread, there is indeed one such compiler in widespread
use: Microsoft Visual Studio.[1]


An older Visual C++ compiler. Not all versions. Anyone could download a
newer compiler for Windows, even Visual C++. See
http://stackoverflow.com/questions/9610747/which-c99-features-are-available-in-the-ms-visual-studio-compiler
for some commentary on feature support.

Windows doesn't come with a compiler, so telling someone on Windows they
need a newer compiler isn't the end of the world, necessarily. Not all
platforms have as much support as Windows. Not that one needs to support
all those platforms. Say cc65... Probably isn't going to ever work.

Despite the fact that the Windows API is defined in terms of C,


ANSI C. And C++. And C# / CLR. Just not C99.
___
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

[James K. Lowden]

On Tue, 31 Jan 2017 15:50:08 -0800
Nathan Bossett  wrote:

> Since this is the sqlite users list and not the dev's list, can I ask
> what your use case is that writing a thin wrapper around SQLITE
> doesn't solve your problem?  

I've encountered no problem compiling SQLite header files as C11.  

The OP encountered a problem compiling SQLite itself as C89 because
there was a C99 construct his compiler didn't support.  The fix was to
"update" the code to conform to a 17-year old standard.  

I wondered aloud what system still exists that supports only C89.  On
review of this thread, there is indeed one such compiler in widespread
use: Microsoft Visual Studio.[1]

Despite the fact that the Windows API is defined in terms of C,
Microsoft evidently and probably correctly has decided its market does
not demand a modern C compiler.  

Last year there was much rejoicing when Microsoft decided to bundle
SQLite with Windows.  That leaves me with a new question: if SQLite
announced its intention to move to C11 in 2018, would that perhaps
influence Microsoft's timeline to update its compiler?  

--jkl

[1]
https://msdn.microsoft.com/en-us/library/hh409293.aspx#ISO%20C/C++%20Standards%20Support
  

___
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

[Nathan Bossett]

On Tue, Jan 31, 2017 at 11:48:10AM -0500, James K. Lowden wrote:
> On Mon, 30 Jan 2017 13:32:46 -0700
> Scott Robison  wrote:
> 
> > Basing source on "ANSI C" (as much as possible) just gives you the
> > biggest possible distribution / compatibility. 
> 
> Yes, but it also limits you to C as it stood 20 years ago.  And
> counting.  Is there no point at which a more recent standard should be
> adopted?  Among features of C11 I use:
> 
>   stdint.h
>   stdbool.h
>   VLA
>   designated initialization
> 
> SQLite would benefit from all of those, plus UTF-8 string constants.  

Since this is the sqlite users list and not the dev's list, can I ask
what your use case is that writing a thin wrapper around SQLITE doesn't
solve your problem?  

For example, I didn't like the amount of boilerplate code I was writing
for database calls and wanted classes plus exceptions, so I wrote
the thin wrapper sqLITER in very basic C++.  Ok, the name wasn't very 
creative and it's only a few pages of code, but it gave me the wide
support and even file format of SQLITE and the greater efficiency
and maintainability of a higher level language.
sqliter.org  (haven't pushed the exceptions code yet)

-Nathan
___
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

[Scott Robison]

On Tue, Jan 31, 2017 at 9:48 AM, James K. Lowden 
wrote:

> On Mon, 30 Jan 2017 13:32:46 -0700
> Scott Robison  wrote:
>
> > Basing source on "ANSI C" (as much as possible) just gives you the
> > biggest possible distribution / compatibility.
>
> Yes, but it also limits you to C as it stood 20 years ago.  And
> counting.  Is there no point at which a more recent standard should be
> adopted?  Among features of C11 I use:
>
> stdint.h
> stdbool.h
> VLA
> designated initialization
>

{snipped}


>
> Knowing what I do of the philosophy of the SQLite developers -- if we
> can speak of such -- I honestly think they (you) would find C11
> amenable.  It's a better language.  It's every bit as respectful of its
> environment, and is more standardized and more easily conformed to it.
>

I agree with all your points regarding the superiority of C99 to ANSI C.
The only downside to it is the "baked in" compatibility. I'm not aware of
any C99 conforming compiler that does not also claim to support C89, but
not vice versa.

It doesn't really matter much to me, as I'm not personally trying to target
such platforms. When I write my own code, I prefer C++11 or later,
personally. But I'm not trying to provide a robust library that works
practically everywhere, either.

-- 
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

[James K. Lowden]

On Mon, 30 Jan 2017 13:32:46 -0700
Scott Robison  wrote:

> Basing source on "ANSI C" (as much as possible) just gives you the
> biggest possible distribution / compatibility. 

Yes, but it also limits you to C as it stood 20 years ago.  And
counting.  Is there no point at which a more recent standard should be
adopted?  Among features of C11 I use:

stdint.h
stdbool.h
VLA
designated initialization

SQLite would benefit from all of those, plus UTF-8 string constants.  

I full well understand the workarounds for integer sizes and Booleans
are baked into SQLite, and there's no real need to adopt the new (er,
new-ish) forms.  VLAs and designated initializers should not be
underestimated, though.  There are many places in SQLite where VLAs
could replace local malloc/free pairs, and SQLite code is rife with
structures that can be more succintly initialized with the modern
syntax.  

> [iBook] 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

In 2002, that might have been the best available.  15 years later, I
suspect better compilers are available for that OS.  The state of
compilers then is not the question.  The state of compilers now is.  

> 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.

True.  I never thought the original report was problematic or
symptomatic.  

When I took my C out of its rusty scabbard, back around when that iBook
was new, I adhered to my K  None of that size_t stuff for me!  The
Internet visited its instruction, though, and over time I grew to
appreciate why lseek(2) returns off_t and so on.  

Nowawdays, once again making a living writing C code and having the
daily opportunity to experiment the the new language features, I've
come to like them.  C is a sharp-edged language, and has become a bit
fussy as the compilers writers have adopted, as we've discussed here, 
pedantic notions of UB.  OTOH, it's an improvement to relieve the
language of some of its ancient constraints, such as static array sizes
and the prohibition on type-punning in unions (which began as SOP, then
was UB, and is now OK again).  

Knowing what I do of the philosophy of the SQLite developers -- if we
can speak of such -- I honestly think they (you) would find C11
amenable.  It's a better language.  It's every bit as respectful of its
environment, and is more standardized and more easily conformed to it.  

--jkl
___
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

[Scott Robison]

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

[James K. Lowden]

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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[dandl]

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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Hick Gunter]

>-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 <h...@scigames.at> 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

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Richard Hipp]

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.

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.

-- 
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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Keith Medcalf]

On Sunday, 29 January, 2017 19:50, Simon Slavin , said:

> On 30 Jan 2017, at 12:06am, Scott Robison  wrote:
 
> > I'm not sure how big the market is, but there are older computers in use
> > in areas that might be running older OS because anything newer is too
> > bloated.

> The emphasis is shifted to non-modern compilers because a large proportion
> of the literally billions of installations of SQLite are on embedded
> computers, not the sort of computers people sit at and type on.  SQLite is
> inside TVs, TV recorders, WiFi routers, Point Of Sale tills, elevator
> controllers, SatNav units, weather monitoring stations and, my recent
> favourite discovery, those machines in car parks which take your money and
> print your ticket.  Some machines of the above types.  Probably not all of
> them.
 
> Those machines use small cheap processors, designed a long time ago, which
> are addressed with old compilers which support old versions of C.  Ten
> years old is not uncommon, especially if the device doesn’t need to
> support a graphical user interface.

And just how many of these "small cheap" processors running TVs, TV recorders, 
WiFi routers, Point Of Sale tills, elevator controllers, SatNav units, weather 
monitoring stations and those machines in car parks which take your money and 
print your ticket, have the "big computer version" of ICU  compiled into them 
and would be affected in any way by this issue currently under dispute?  

ICU takes more memory than most TV's, TV recorders, Point of Sale tills, 
elevator controllers, SatNav units, weather monitoring stations and those 
machines in car parks which take your money and print your ticket, have 
available -- let alone room to shoehorn in a basic operating system, SQLite3, 
and a program to actually DO something as well.




___
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

[Scott Robison]

On Jan 29, 2017 5:49 PM, "Simon Slavin"  wrote:


On 30 Jan 2017, at 12:06am, Scott Robison  wrote:

> I'm not sure how big the market is, but there are older computers in use
in
> areas that might be running older OS because anything newer is too
bloated.

The emphasis is shifted to non-modern compilers because a large proportion
of the literally billions of installations of SQLite are on embedded
computers, not the sort of computers people sit at and type on.  SQLite is
inside TVs, TV recorders, WiFi routers, Point Of Sale tills, elevator
controllers, SatNav units, weather monitoring stations and, my recent
favourite discovery, those machines in car parks which take your money and
print your ticket.  Some machines of the above types.  Probably not all of
them.


Understood and agreed. I'm just observing that not everyone is even using a
modern machine as a desktop workstation.


Those machines use small cheap processors, designed a long time ago, which
are addressed with old compilers which support old versions of C.  Ten
years old is not uncommon, especially if the device doesn’t need to support
a graphical user interface.

So a round of bringing SQLite3 up to date to support shiny new versions of
C is likely to introduce problems for many programmers unless you’ve hired
the sort of C lawyer who has all the changes in his or her head.  Better to
make changes just when people point out problems.  SQLite4 can be a new
start, with a stated set of compilers supported.

Simon.
___
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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Simon Slavin]

On 30 Jan 2017, at 12:06am, Scott Robison  wrote:

> I'm not sure how big the market is, but there are older computers in use in
> areas that might be running older OS because anything newer is too bloated.

The emphasis is shifted to non-modern compilers because a large proportion of 
the literally billions of installations of SQLite are on embedded computers, 
not the sort of computers people sit at and type on.  SQLite is inside TVs, TV 
recorders, WiFi routers, Point Of Sale tills, elevator controllers, SatNav 
units, weather monitoring stations and, my recent favourite discovery, those 
machines in car parks which take your money and print your ticket.  Some 
machines of the above types.  Probably not all of them.

Those machines use small cheap processors, designed a long time ago, which are 
addressed with old compilers which support old versions of C.  Ten years old is 
not uncommon, especially if the device doesn’t need to support a graphical user 
interface.

So a round of bringing SQLite3 up to date to support shiny new versions of C is 
likely to introduce problems for many programmers unless you’ve hired the sort 
of C lawyer who has all the changes in his or her head.  Better to make changes 
just when people point out problems.  SQLite4 can be a new start, with a stated 
set of compilers supported.

Simon.
___
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

[Scott Robison]

I'm not sure how big the market is, but there are older computers in use in
areas that might be running older OS because anything newer is too bloated.

If maintaining ANSI C compatibility truly becomes a burden, sure. If it
isn't then why not?

On Jan 29, 2017 4:36 PM, "James K. Lowden"  wrote:

> On Sat, 28 Jan 2017 11:49:19 +1100
> "dandl"  wrote:
>
> > >>>Sticking with C90 is perfectly rational if you're still running
> > >>>Windows 98 on a Pentium III at 500 Mhz with 256 MB RAM.  Else,
> > >>>really, it's not too soon to adopt a 6-year old standard, C11.
> >
> > There are plenty of older C compilers used in various niche
> > applications: embedded, pricey vendor dev kit not updated, etc.
> > Obviously not many of them using Sqlite, but you never know...
>
> I wonder what pricey embedded environment both supports dlopen(2) and
> does not support C99, in this day and age.
>
> And I'm unsympathetic. SQLite is in the public domain, so that anyone
> can use it however they like.  That doesn't oblige SQLIte to cater to
> the most unpublic, renegade environments.  If some proprietary software
> can't take advantage of something made freely available, I would wish
> only for tougher noogies.
>
> --jkl
>
> ___
> 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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[James K. Lowden]

On Sat, 28 Jan 2017 11:49:19 +1100
"dandl"  wrote:

> >>>Sticking with C90 is perfectly rational if you're still running
> >>>Windows 98 on a Pentium III at 500 Mhz with 256 MB RAM.  Else,
> >>>really, it's not too soon to adopt a 6-year old standard, C11.  
> 
> There are plenty of older C compilers used in various niche
> applications: embedded, pricey vendor dev kit not updated, etc.
> Obviously not many of them using Sqlite, but you never know...

I wonder what pricey embedded environment both supports dlopen(2) and
does not support C99, in this day and age.  

And I'm unsympathetic. SQLite is in the public domain, so that anyone
can use it however they like.  That doesn't oblige SQLIte to cater to
the most unpublic, renegade environments.  If some proprietary software
can't take advantage of something made freely available, I would wish
only for tougher noogies.  

--jkl

___
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

[Joseph R. Justice]

On Fri, Jan 27, 2017 at 7:49 PM, dandl  wrote:

> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> On Behalf Of James K. Lowden
>


> >>>Sticking with C90 is perfectly rational if you're still running Windows
> 98 on a Pentium III at 500 Mhz with 256 MB RAM.  Else, really, it's not too
> soon to adopt a 6-year old standard, C11.
>
> There are plenty of older C compilers used in various niche applications:
> embedded, pricey vendor dev kit not updated, etc. Obviously not many of
> them using Sqlite, but you never know...
>

I would have thought that embedded was a specific target niche for SQLite?
At least, for embedded products that need more than Berkeley DB, etc...

Hmmm.  Is it known how many / which RT OSen, embedded OSen, etc have
(public) ports of SQLite to them?  (I'll respect that, for competitive
reasons, some RT / embedded OSen might not make it public that they have
SQLite ported to them.)



Joseph
___
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

[dandl]

From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of James K. Lowden

>>>Sticking with C90 is perfectly rational if you're still running Windows 98 
>>>on a Pentium III at 500 Mhz with 256 MB RAM.  Else, really, it's not too 
>>>soon to adopt a 6-year old standard, C11.  

There are plenty of older C compilers used in various niche applications: 
embedded, pricey vendor dev kit not updated, etc. Obviously not many of them 
using Sqlite, but you never know...

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

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Richard Damon]

On 1/27/17 6:06 PM, Keith Medcalf wrote:


On Friday, 27 January, 2017 08:26, Clemens Ladisch  said:


David Empson wrote:

Perhaps SQLite’s test procedure should be enforcing strict ANSI C mode?
If this is already being done, then the compiler(s) used might not be
enforcing this particular rule.

"gcc -pedantic -std=c90" (or gnu90) would check for this error:

test.c:6:3: warning: initializer element is not computable at load time [-
Wpedantic]

But the error message/warning is of high bogosity.

While it is true that the initializer element cannot be computed at "load" time, it is not a "load time" item 
that is being initialized.  The item being initialized is a dynamic element on the stack inside a function call and it is 
initialized from a function argument.  It is entirely irrelevant that the element cannot be computed at "load time" 
because computing it thusly would be of no use whatsoever -- initialization of items residing on a functions call stack must 
always be done at "run time" and can never be done at "load time".

So the erroneous warning should just be ignored and a bug report filed against 
the compiler.

except that the C90 standard apparently says that aggregates (like 
this), need to be initialized to a constant (load time), possibly to 
allow the function to initialize the variable with a memcpy (or 
equivalent) from a constant initialization buffer. C99 apparently 
decided that rather than making the programmer make the transformation 
to update a few 'call time' values, it was better to make the compiler 
do that work (as it would be less error prone).


--
Richard Damon

___
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

[Keith Medcalf]

On Friday, 27 January, 2017 08:26, Clemens Ladisch  said:

> David Empson wrote:
> > Perhaps SQLite’s test procedure should be enforcing strict ANSI C mode?
> > If this is already being done, then the compiler(s) used might not be
> > enforcing this particular rule.
> 
> "gcc -pedantic -std=c90" (or gnu90) would check for this error:
> 
> test.c:6:3: warning: initializer element is not computable at load time [-
> Wpedantic]

But the error message/warning is of high bogosity.

While it is true that the initializer element cannot be computed at "load" 
time, it is not a "load time" item that is being initialized.  The item being 
initialized is a dynamic element on the stack inside a function call and it is 
initialized from a function argument.  It is entirely irrelevant that the 
element cannot be computed at "load time" because computing it thusly would be 
of no use whatsoever -- initialization of items residing on a functions call 
stack must always be done at "run time" and can never be done at "load time".

So the erroneous warning should just be ignored and a bug report filed against 
the compiler.




___
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

[James K. Lowden]

On Fri, 27 Jan 2017 10:08:17 +1300
David Empson  wrote:

> Should SQLite be aiming for the 1990 version of ANSI/ISO C as a
> baseline, for widest compatibility, or is it OK to drop older
> compilers and require C99 compliance?

Older compilers?  C99 was adopted 17 years ago, and most of the changes
it standardardized had by then already been implemented by more than one
compiler.  

Sticking with C90 is perfectly rational if you're still running 
Windows 98 on a Pentium III at 500 Mhz with 256 MB RAM.  Else, really,
it's not too soon to adopt a 6-year old standard, C11.  

--jkl


___
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

[James K. Lowden]

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
___
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

[Clemens Ladisch]

I wrote:
> David Empson wrote:
>> Perhaps SQLite’s test procedure should be enforcing strict ANSI C mode?
>> If this is already being done, then the compiler(s) used might not be
>> enforcing this particular rule.
>
> "gcc -pedantic -std=c90" (or gnu90) would check for this error

And tool/warnings.sh already uses it, but not for the Android configuration,
which is the only one that enables ICU.


Regards,
Clemens
___
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

[Kim Gräsman]

David,

On Fri, Jan 27, 2017 at 12:51 PM, David Empson  wrote:
>
>> On 27/01/2017, at 9:09 PM, Kim Gräsman  wrote:
>>
>> On Thu, Jan 26, 2017 at 10:08 PM, David Empson > > wrote:
>>>
 On 26/01/2017, at 8:46 PM, Clemens Ladisch  wrote:

> …
>  {"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
> };
>>>
>>> The ANSI/ISO C 1990 standard states this in section 6.5.7, under 
>>> Constraints:
>>>
>>> “All the expressions in an initializer for an object that has static 
>>> storage duration or in an initializer list for an object that has aggregate 
>>> or union type shall be constant expressions.”
>>
>> But this object doesn't have static storage duration, does it?
>> `scalars` is just a local variable in a function:
>> https://sourcecodebrowser.com/sqlite3/3.6.21/icu_8c_source.html#l00449 
>> 
>>
>> unless I'm looking at the wrong version.
>
> That version does have the text quoted above.
>
> The problem is that ANSI/ISO C 1990 stipulates that an initializer for any 
> object of aggregate type, whether or not it is static, must be constant.

Ah, misread the part about aggregate types in general. Sorry about the noise!

- Kim
___
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

[Clemens Ladisch]

David Empson wrote:
> Perhaps SQLite’s test procedure should be enforcing strict ANSI C mode?
> If this is already being done, then the compiler(s) used might not be
> enforcing this particular rule.

"gcc -pedantic -std=c90" (or gnu90) would check for this error:

test.c:6:3: warning: initializer element is not computable at load time 
[-Wpedantic]

> [...]
> Therefore Visual C++ 2008 does have extensions to ANSI C90 which allow
> a non-constant initializer for an aggregate type with auto storage.
> (I also tested Visual C++ 98 and it worked there too.)
>
> However if I tell Visual C++ to enable strict ANSI C mode by adding
> the /Za command line option, I get an error:
>
> test.c(45) : error C2097: illegal initialization

So neither compiler complains unless you explicitly tell it to.
(But that extra checking _is_ useful for compatibility.)


Regards,
Clemens
___
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

[David Empson]

> On 27/01/2017, at 9:09 PM, Kim Gräsman  wrote:
> 
> On Thu, Jan 26, 2017 at 10:08 PM, David Empson  > wrote:
>> 
>>> On 26/01/2017, at 8:46 PM, Clemens Ladisch  wrote:
>>> 
 …
  {"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
 };
>> 
>> The ANSI/ISO C 1990 standard states this in section 6.5.7, under Constraints:
>> 
>> “All the expressions in an initializer for an object that has static storage 
>> duration or in an initializer list for an object that has aggregate or union 
>> type shall be constant expressions.”
> 
> But this object doesn't have static storage duration, does it?
> `scalars` is just a local variable in a function:
> https://sourcecodebrowser.com/sqlite3/3.6.21/icu_8c_source.html#l00449 
> 
> 
> unless I'm looking at the wrong version.

That version does have the text quoted above.

The problem is that ANSI/ISO C 1990 stipulates that an initializer for any 
object of aggregate type, whether or not it is static, must be constant.

It doesn’t matter that this variable has auto storage - it is an aggregate type 
(array of structs), and the initializer for an aggregate type must be constant 
if a compiler is enforcing ANSI/ISO C 1990 rules (or is based on C90 but hasn’t 
implemented extensions to allow a non-constant initializer for an aggregate 
type).

As I noted, C99 changed the rules and does allow a non-constant initializer in 
this case.

The code in question has been there since May 2007, so the fact that nobody 
reported it until now suggests that almost nobody who uses the ICU extension is 
doing so with a strict ANSI C90 compiler (or a compiler set to enforce C90 
rules).

Perhaps SQLite’s test procedure should be enforcing strict ANSI C mode? If this 
is already being done, then the compiler(s) used might not be enforcing this 
particular rule.

> Again, it would be nice to see the actual warning from MSVC.

Indeed.

As it happens, I have an installation of Visual C++ 2008 so can test this, not 
using icu.c as I don’t have necessary support files installed, but I can create 
a mockup using a copy of the sqlite3IcuInit function with stubs for everything 
it references.

Using default options from the command line, my test file compiles without 
error.

Therefore Visual C++ 2008 does have extensions to ANSI C90 which allow a 
non-constant initializer for an aggregate type with auto storage. (I also 
tested Visual C++ 98 and it worked there too.)

However if I tell Visual C++ to enable strict ANSI C mode by adding the /Za 
command line option, I get an error:


[C:\p\test]cl /Za test.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c
test.c(45) : error C2097: illegal initialization


This is consistent with the rule I noted from ANSI/ISO C 1990.

For reference, here is my test.c:


typedef struct { int a; } sqlite3;
typedef struct { int b; } sqlite3_context;
typedef struct { int c; } sqlite3_value;

#define SQLITE_ANY  1
#define SQLITE_DETERMINISTIC2
#define SQLITE_UTF164
#define SQLITE_UTF8 8

#define SQLITE_OK   0

void icuRegexpFunc(sqlite3_context*c, int i, sqlite3_value**vpp) { }
void icuCaseFunc16(sqlite3_context*c, int i, sqlite3_value**vpp) { }
void icuLikeFunc(sqlite3_context*c, int i, sqlite3_value**vpp) { }
void icuLoadCollation(sqlite3_context*c, int i, sqlite3_value**vpp) { }

int sqlite3_create_function(sqlite3 *db, const char *zName, int nArg, int enc, 
void *pContext,
void 
(*xFunc)(sqlite3_context*,int,sqlite3_value**), int i, int j) {
  return SQLITE_OK;
}

int sqlite3IcuInit(sqlite3 *db){
  struct IcuScalar {
const char *zName;/* Function name */
int nArg; /* Number of arguments */
int enc;  /* Optimal text encoding */
void *pContext;   /* sqlite3_user_data() context */
void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
  } scalars[] = {
{"regexp", 2, SQLITE_ANY|SQLITE_DETERMINISTIC,  0, icuRegexpFunc},

{"lower",  1, SQLITE_UTF16|SQLITE_DETERMINISTIC,0, icuCaseFunc16},
{"lower",  2, SQLITE_UTF16|SQLITE_DETERMINISTIC,0, icuCaseFunc16},
{"upper",  1, SQLITE_UTF16|SQLITE_DETERMINISTIC, (void*)1, icuCaseFunc16},
{"upper",  2, SQLITE_UTF16|SQLITE_DETERMINISTIC, (void*)1, icuCaseFunc16},

{"lower",  1, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuCaseFunc16},
{"lower",  2, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuCaseFunc16},
{"upper",  1, SQLITE_UTF8|SQLITE_DETERMINISTIC,  (void*)1, icuCaseFunc16},
{"upper",  

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Kim Gräsman]

On Thu, Jan 26, 2017 at 10:08 PM, David Empson  wrote:
>
>> On 26/01/2017, at 8:46 PM, Clemens Ladisch  wrote:
>>
>> Ziemowit Laski wrote:
>>> Visual C++
>>
>> Which one?
>>
>>> correctly catches this.
>>
>> Oh?  What exactly is illegal about this?
>>
>>>  struct IcuScalar {
>>>const char *zName;/* Function name */
>>>int nArg; /* Number of arguments */
>>>int enc;  /* Optimal text encoding */
>>>void *pContext;   /* sqlite3_user_data() context 
>>> */
>>>void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>>>  } scalars[] = {
>>>...
>>>{"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>>>  };
>
> The ANSI/ISO C 1990 standard states this in section 6.5.7, under Constraints:
>
> “All the expressions in an initializer for an object that has static storage 
> duration or in an initializer list for an object that has aggregate or union 
> type shall be constant expressions.”

But this object doesn't have static storage duration, does it?
`scalars` is just a local variable in a function:
https://sourcecodebrowser.com/sqlite3/3.6.21/icu_8c_source.html#l00449

unless I'm looking at the wrong version.

Again, it would be nice to see the actual warning from MSVC.

FWIW,
- Kim
___
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

[Dominique Devienne]

On Fri, Jan 27, 2017 at 1:24 AM, Richard Hipp  wrote:

> On 1/26/17, dandl  wrote:
> >
> > 1. Why was VS the first compiler to detect this?
>
> Perhaps VS is the only compiler still in frequent use that does not
> support C99?


I guess David's question can also be rephrased as to why didn't the SQLite
team's
internal CI detect this before the community did?

SQLite is known for its outstanding testing in general, so I guess it's
surprising that if it
targets ANSI C 1989/1990 compatibility there isn't a build-bot that checks
this continuously. --DD
___
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

[Richard Hipp]

On 1/26/17, dandl  wrote:
>
> 1. Why was VS the first compiler to detect this?

Perhaps VS is the only compiler still in frequent use that does not support C99?

> 2. Is there an authoritative view on which standard Sqlite should comply
> with?
>

SQLite should compile with VS.  I checked in a fix for the problem
here: https://www.sqlite.org/src/info/50e60cb44fd3687d

-- 
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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[dandl]

From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of David Empson

>>>The ANSI/ISO C 1990 standard states this in section 6.5.7, under Constraints:
>>>“All the expressions in an initializer for an object that has static storage 
>>>duration or in an initializer list for an object that has aggregate or union 
>>>type shall be constant expressions.”

>>>In this case the code is trying to initialize a field of an auto struct 
>>>using the db parameter passed to the function. That is not a constant 
>>>expression, and it is in an initializer list for an object that has 
>>>aggregate type (whether or not the object has static storage duration), so 
>>>is disallowed under ANSI/ISO C 1990.

>>>Later versions of the C standard removed the bit about aggregate or union 
>>>types, leaving only the static restriction, e.g. from section 6.7.8 of the 
>>>draft C99 standard:
>>>"All the expressions in an initializer for an object that has static storage 
>>>duration shall be constant expressions or string literals.”

I can confirm that. So in summary, the Sqlite code is not valid ANSI C (1990) 
but it is valid according to the C99 standard. It's only broken for old 
compilers, not new ones.

1. Why was VS the first compiler to detect this?
2. Is there an authoritative view on which standard Sqlite should comply with?

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

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[David Empson]

> On 26/01/2017, at 8:46 PM, Clemens Ladisch  wrote:
> 
> Ziemowit Laski wrote:
>> Visual C++
> 
> Which one?
> 
>> correctly catches this.
> 
> Oh?  What exactly is illegal about this?
> 
>>  struct IcuScalar {
>>const char *zName;/* Function name */
>>int nArg; /* Number of arguments */
>>int enc;  /* Optimal text encoding */
>>void *pContext;   /* sqlite3_user_data() context 
>> */
>>void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>>  } scalars[] = {
>>...
>>{"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>>  };

The ANSI/ISO C 1990 standard states this in section 6.5.7, under Constraints:

“All the expressions in an initializer for an object that has static storage 
duration or in an initializer list for an object that has aggregate or union 
type shall be constant expressions.”

In this case the code is trying to initialize a field of an auto struct using 
the db parameter passed to the function. That is not a constant expression, and 
it is in an initializer list for an object that has aggregate type (whether or 
not the object has static storage duration), so is disallowed under ANSI/ISO C 
1990.

Later versions of the C standard removed the bit about aggregate or union 
types, leaving only the static restriction, e.g. from section 6.7.8 of the 
draft C99 standard:

"All the expressions in an initializer for an object that has static storage 
duration shall be constant expressions or string literals.”

Visual C++ is based on C90, and assuming Wikipedia has the details right, it 
wasn’t until Visual C++ 2013 that Microsoft started making changes to support 
C99.

Should SQLite be aiming for the 1990 version of ANSI/ISO C as a baseline, for 
widest compatibility, or is it OK to drop older compilers and require C99 
compliance?

The only obvious reference I found in the SQLite documentation was 
http://www.sqlite.org/howtocompile.html which mentions “ANSI-C”. That is 
generally understood to mean the ANSI C 1989 standard, which was adopted 
internationally as ISO 9899:1990.

-- 
David Empson
demp...@emptech.co.nz

___
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

[Richard Damon]

On 1/26/17 8:05 AM, Hick Gunter wrote:

The OP proposes intializing the structure member with "0" instead of "(void*)db", 
which I read the other way around and reminds me of certain implicit equivalences 0 <==> (void*)0, 
on eof which was recently discussed here.

Perhaps the OP's Compiler does not allow initialization of a dynamic structure 
with a parameter value.

If the structure is a static/global, then the initializers need to be 
compile time constants for C. If this is a function local object (which 
it looks like), that initialization with a variable is perfectly legal 
(but perhaps VC is warning that the presence of the variable is going to 
make that initilization less efficient, as it can't just make a static 
copy of the initialization value and memcpy that to the variable).



--
Richard Damon

___
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

[dandl]

>>>From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
>>>Behalf Of Ziemowit Laski
Sent: Thursday, 26 January 2017 7:36 AM
To: sqlite-users@mailinglists.sqlite.org
Subject: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit
>>>
>>>Visual C++ correctly catches this.  The fragment
>>>
>>>  struct IcuScalar {
>>>const char *zName;/* Function name */
>>>int nArg; /* Number of arguments */
>>>int enc;  /* Optimal text encoding */
>>>void *pContext;   /* sqlite3_user_data() context 
>>> */
>>>void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>>>  } scalars[] = {
>>>{"regexp", 2, SQLITE_ANY|SQLITE_DETERMINISTIC,  0, 
>>> icuRegexpFunc},
>>>
>>>{"lower",  1, SQLITE_UTF16|SQLITE_DETERMINISTIC,0, 
>>> icuCaseFunc16},
>>>{"lower",  2, SQLITE_UTF16|SQLITE_DETERMINISTIC,0, 
>>> icuCaseFunc16},
>>>{"upper",  1, SQLITE_UTF16|SQLITE_DETERMINISTIC, (void*)1, 
>>> icuCaseFunc16},
>>>{"upper",  2, SQLITE_UTF16|SQLITE_DETERMINISTIC, (void*)1, 
>>> icuCaseFunc16},
>>>
>>>{"lower",  1, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, 
>>> icuCaseFunc16},
>>>{"lower",  2, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, 
>>> icuCaseFunc16},
>>>{"upper",  1, SQLITE_UTF8|SQLITE_DETERMINISTIC,  (void*)1, 
>>> icuCaseFunc16},
>>>{"upper",  2, SQLITE_UTF8|SQLITE_DETERMINISTIC,  (void*)1, 
>>> icuCaseFunc16},
>>>
>>>{"like",   2, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuLikeFunc},
>>>{"like",   3, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuLikeFunc},
>>>
>>>{"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>>>  };
>>>
>>>  int rc = SQLITE_OK;
>>>  int i;
>>>
>>>should read
>>>
>>>   struct IcuScalar {
>>>  const char *zName;/* Function name */
>>>  int nArg; /* Number of 
>>> arguments */
>>>  int enc;  /* Optimal text 
>>> encoding */
>>>  void *pContext;   /* 
>>> sqlite3_user_data() context */
>>>  void(*xFunc)(sqlite3_context*, int, sqlite3_value**);
>>>   } scalars[] = {
>>>  { "regexp", 2, SQLITE_ANY | SQLITE_DETERMINISTIC,  0, 
>>> icuRegexpFunc },
>>>
>>>  { "lower",  1, SQLITE_UTF16 | SQLITE_DETERMINISTIC,0, 
>>> icuCaseFunc16 },
>>>  { "lower",  2, SQLITE_UTF16 | SQLITE_DETERMINISTIC,0, 
>>> icuCaseFunc16 },
>>>  { "upper",  1, SQLITE_UTF16 | SQLITE_DETERMINISTIC, (void*)1, 
>>> icuCaseFunc16 },
>>>  { "upper",  2, SQLITE_UTF16 | SQLITE_DETERMINISTIC, (void*)1, 
>>> icuCaseFunc16 },
>>>
>>>  { "lower",  1, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
>>> icuCaseFunc16 },
>>>  { "lower",  2, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
>>> icuCaseFunc16 },
>>>  { "upper",  1, SQLITE_UTF8 | SQLITE_DETERMINISTIC,  (void*)1, 
>>> icuCaseFunc16 },
>>>  { "upper",  2, SQLITE_UTF8 | SQLITE_DETERMINISTIC,  (void*)1, 
>>> icuCaseFunc16 },
>>>
>>>  { "like",   2, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
>>> icuLikeFunc },
>>>  { "like",   3, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
>>> icuLikeFunc },
>>>
>>>  { "icu_load_collation",  2, SQLITE_UTF8, 0, icuLoadCollation }
>>>   };
>>>
>>>   int rc = SQLITE_OK;
>>>   int i;
>>>
>>>   scalars[11].pContext = (void*)db;
>>>

Why would you say that? What error message are you getting on what compiler, 
and why would that change produce any different result? What type is 'db'?

Can you quote some specified reference to the C standard document in support of 
your contention?

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

Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Hick Gunter]

The OP proposes intializing the structure member with "0" instead of 
"(void*)db", which I read the other way around and reminds me of certain 
implicit equivalences 0 <==> (void*)0, on eof which was recently discussed here.

Perhaps the OP's Compiler does not allow initialization of a dynamic structure 
with a parameter value.

-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von Clemens Ladisch
Gesendet: Donnerstag, 26. Jänner 2017 13:07
An: sqlite-users@mailinglists.sqlite.org
Betreff: Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

Hick Gunter wrote:
> On ILP_32 architectures, the integer 0

What integer 0?  The message is about initializing scalars[11].pContent (a 
"void*") with "(void*)db", which is "sqlite3*".

> Oh?  What exactly is illegal about this?
>
>>   struct IcuScalar {
>> const char *zName;/* Function name */
>> int nArg; /* Number of arguments */
>> int enc;  /* Optimal text encoding */
>> void *pContext;   /* sqlite3_user_data() context 
>> */
>> void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>>   } scalars[] = {
>> ...
>> {"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>>   };
>>
>> should read
>>
>>} scalars[] = {
>>   ...

Look right below here...

>>   { "icu_load_collation",  2, SQLITE_UTF8, 0, icuLoadCollation }
>>};
>>

Look just above here...

>>scalars[11].pContext = (void*)db;


Regards,
Clemens
___
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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Clemens Ladisch]

Hick Gunter wrote:
> On ILP_32 architectures, the integer 0

What integer 0?  The message is about initializing scalars[11].pContent
(a "void*") with "(void*)db", which is "sqlite3*".

> Oh?  What exactly is illegal about this?
>
>>   struct IcuScalar {
>> const char *zName;/* Function name */
>> int nArg; /* Number of arguments */
>> int enc;  /* Optimal text encoding */
>> void *pContext;   /* sqlite3_user_data() context 
>> */
>> void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>>   } scalars[] = {
>> ...
>> {"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>>   };
>>
>> should read
>>
>>} scalars[] = {
>>   ...
>>   { "icu_load_collation",  2, SQLITE_UTF8, 0, icuLoadCollation }
>>};
>>
>>scalars[11].pContext = (void*)db;


Regards,
Clemens
___
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

[Hick Gunter]

On ILP_32 architectures, the integer 0 is not discernible from the (void *)0 
(aka NULL) and so most compilers don't bother to issue a warning. This comes 
from an age where programmers were expected to know how computers work on an 
assembly language level and would "know what they are doing" when passing an 
integer of the same size to a pointer argument.

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. Additionally, compilers have become more pedantic (because 
compiler builders have become aware of the fact that not "knowing what you are 
doing" in respect to pointers and integers is a common source of errors) and 
will complain about "making a pointer from an integer of a different size" 
and/or "making a pointer from an integer without a cast".

There are many casese of 0 vs. NULL in sqlite code; they do not, however, 
influence the operation of the code, just compileability in "nit picking" mode.

-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von Clemens Ladisch
Gesendet: Donnerstag, 26. Jänner 2017 08:47
An: sqlite-users@mailinglists.sqlite.org
Betreff: Re: [sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

Ziemowit Laski wrote:
> Visual C++

Which one?

> correctly catches this.

Oh?  What exactly is illegal about this?

>   struct IcuScalar {
> const char *zName;/* Function name */
> int nArg; /* Number of arguments */
> int enc;  /* Optimal text encoding */
> void *pContext;   /* sqlite3_user_data() context 
> */
> void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>   } scalars[] = {
> ...
> {"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>   };
>
> should read
>
>} scalars[] = {
>   ...
>   { "icu_load_collation",  2, SQLITE_UTF8, 0, icuLoadCollation }
>};
>
>scalars[11].pContext = (void*)db;


Regards,
Clemens
___
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] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Clemens Ladisch]

Ziemowit Laski wrote:
> Visual C++

Which one?

> correctly catches this.

Oh?  What exactly is illegal about this?

>   struct IcuScalar {
> const char *zName;/* Function name */
> int nArg; /* Number of arguments */
> int enc;  /* Optimal text encoding */
> void *pContext;   /* sqlite3_user_data() context 
> */
> void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
>   } scalars[] = {
> ...
> {"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
>   };
>
> should read
>
>} scalars[] = {
>   ...
>   { "icu_load_collation",  2, SQLITE_UTF8, 0, icuLoadCollation }
>};
>
>scalars[11].pContext = (void*)db;


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

[sqlite] BUG: Illegal initialization in icu.c : sqlite3IcuInit

[Ziemowit Laski]

Visual C++ correctly catches this.  The fragment

  struct IcuScalar {
const char *zName;/* Function name */
int nArg; /* Number of arguments */
int enc;  /* Optimal text encoding */
void *pContext;   /* sqlite3_user_data() context */
void (*xFunc)(sqlite3_context*,int,sqlite3_value**);
  } scalars[] = {
{"regexp", 2, SQLITE_ANY|SQLITE_DETERMINISTIC,  0, icuRegexpFunc},

{"lower",  1, SQLITE_UTF16|SQLITE_DETERMINISTIC,0, icuCaseFunc16},
{"lower",  2, SQLITE_UTF16|SQLITE_DETERMINISTIC,0, icuCaseFunc16},
{"upper",  1, SQLITE_UTF16|SQLITE_DETERMINISTIC, (void*)1, icuCaseFunc16},
{"upper",  2, SQLITE_UTF16|SQLITE_DETERMINISTIC, (void*)1, icuCaseFunc16},

{"lower",  1, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuCaseFunc16},
{"lower",  2, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuCaseFunc16},
{"upper",  1, SQLITE_UTF8|SQLITE_DETERMINISTIC,  (void*)1, icuCaseFunc16},
{"upper",  2, SQLITE_UTF8|SQLITE_DETERMINISTIC,  (void*)1, icuCaseFunc16},

{"like",   2, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuLikeFunc},
{"like",   3, SQLITE_UTF8|SQLITE_DETERMINISTIC, 0, icuLikeFunc},

{"icu_load_collation",  2, SQLITE_UTF8, (void*)db, icuLoadCollation},
  };

  int rc = SQLITE_OK;
  int i;

should read

   struct IcuScalar {
  const char *zName;/* Function name */
  int nArg; /* Number of arguments 
*/
  int enc;  /* Optimal text 
encoding */
  void *pContext;   /* sqlite3_user_data() 
context */
  void(*xFunc)(sqlite3_context*, int, sqlite3_value**);
   } scalars[] = {
  { "regexp", 2, SQLITE_ANY | SQLITE_DETERMINISTIC,  0, 
icuRegexpFunc },

  { "lower",  1, SQLITE_UTF16 | SQLITE_DETERMINISTIC,0, 
icuCaseFunc16 },
  { "lower",  2, SQLITE_UTF16 | SQLITE_DETERMINISTIC,0, 
icuCaseFunc16 },
  { "upper",  1, SQLITE_UTF16 | SQLITE_DETERMINISTIC, (void*)1, 
icuCaseFunc16 },
  { "upper",  2, SQLITE_UTF16 | SQLITE_DETERMINISTIC, (void*)1, 
icuCaseFunc16 },

  { "lower",  1, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
icuCaseFunc16 },
  { "lower",  2, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
icuCaseFunc16 },
  { "upper",  1, SQLITE_UTF8 | SQLITE_DETERMINISTIC,  (void*)1, 
icuCaseFunc16 },
  { "upper",  2, SQLITE_UTF8 | SQLITE_DETERMINISTIC,  (void*)1, 
icuCaseFunc16 },

  { "like",   2, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
icuLikeFunc },
  { "like",   3, SQLITE_UTF8 | SQLITE_DETERMINISTIC, 0, 
icuLikeFunc },

  { "icu_load_collation",  2, SQLITE_UTF8, 0, icuLoadCollation }
   };

   int rc = SQLITE_OK;
   int i;

   scalars[11].pContext = (void*)db;

Thank you,

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