But there is no API which will permit you to retrieve "unsigned" integers from SQLite3. Nor is there an API which will let you "send" an unsigned integer to SQLite3 for storage in the database. All the sqlite3_column and sqlite3_bind interfaces deal only with signed integers.
If you are using using compiler magic (ie, a cast) to fiddle-diddle with the declared interpretation of the SQLite3 APIs, then it is probably best that you know what you are doing. (Similarly if you use "some bits" of a pointer for other than their intended purpose (that is, pointing to an address in linear virtual memory) then you should expect the explosions and faults which will ensue). It is entirely possible to use a bag-o-bytes to declare all data values in your application, and then use compiler magic (ie, casts) to cause the compiler into generating whatever machine code your little heart might desire, however, you better really really know what you are doing if you go that route. The same applies if you expect SQLite3 to behave in a manner different than having only the datatypes integer, double, text, and bag-o-bytes, and using prayerful declarations that do not reflect the inherent data interfaces falls into the same bucket. In other words, what is stored is what you put, and what you get back is what you asked for. If you want to know what was put, you need to ask. If you don't ask and make an assumption, then you best be prepared to deal with the result of what was put converted to what you asked for. So what you really want is (a) to be able to error-out on SQL operations that do not use proper affinity words (ie, only accept INTEGER, DOUBLE, TEXT and BLOB), and; (b) to crash or return an error instead of converting the data that you put or at least, that you ask. That way at least if you use a stupid table declaration like CREATE TABLE theTable (theColumn unsigned integer(1024)); you will get a syntax error since neither the word "unsigned" nor a value in (brackets) are proper affinity declarations. Similarly if a datavalue is "text" and you ask for an "integer" you get an error since you are not "asking" for data which matches what was stored. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Warren Young >Sent: Friday, 29 June, 2018 19:35 >To: SQLite mailing list >Subject: Re: [sqlite] column types and constraints > >On Jun 29, 2018, at 4:36 PM, Keith Medcalf <kmedc...@dessus.com> >wrote: >> >> All of the issues raised are "application" problems, not database >problems. > >Computers are here to aid humans, not the other way around. > >> Clearly if you retrieved a value from the database and want to use >it as an index you have to do bounds checking. > >Why? I told the DBMS that the values in that column will be unsigned >integers, yet it accepted a non-integer for storage and then yielded >a negative value on retrieval. > >This code will yield a complaint from a sufficiently on-the-ball C >compiler: > > unsigned foo = external_function(); > if (foo >= 0) do_happy_path(); > >It will rightly complain that the condition is always true. > >> The ability to forsee that the world may not be entirely as you >expect is the root of the difference between a mere coder and a >professional software programmer. > >Therefore, all of the bugs written in C that we can attribute to >language design issues were perpetrated by mere coders. No true >Scotsman^Wprogrammer would ever make such a mistake. Compiler >diagnostics are for the weak. TODAY IS A GOOD DAY TO WRITE SOFTWARE. >_______________________________________________ >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
