SQLite Forum

sqlite3_carray_bind and constness
Login

sqlite3_carray_bind and constness

(1) By Marco Bubke (marcob) on 2021-07-22 10:29:43 [link]

sqlite3_carray_bind is using a non const pointer which is forcing a copy if you
use const data. You can cast to non const but then you are in undefined behavior area. A const version like sqlite3_const_carray_bind could prevent bugs in that erroneous usage. Or is there an other way?

(2) By Larry Brasfield (larrybr) on 2021-07-22 13:39:09 in reply to 1 [link]

Because the virtual table is read-only as seen by its users from SQLite, you could just enforce const correctness in ext/misc/carray.{c,h} . Until the code supports update/insert/delete (by giving the virtual table implementation an xUpdate method), there is no reason that input cannot be treated as const.

(3) By Marco Bubke (marcob) on 2021-07-25 19:11:21 in reply to 2

But then you run into int sqlite3_bind_pointer(sqlite3_stmt*, int, void*, const char*,void(*)(void*)) where the pointer is not const. I imagine adding sqlite3_bind_const_pointer will result into internal changes. sqlite3_bind_blob is const but ...

(4) By Larry Brasfield (larrybr) on 2021-07-25 20:21:26 in reply to 3 [link]

If SQLite, along with its collection of external demos and aids, was purported to be a C++ library, then bug reports resembling "X is not const-correct" or "Y should be more const-accepting" would be taken and likely acted upon.

What I am saying (in post #2) is that you could rewrite ext/misc/carray.{c,h} to make it more const-accepting with no changes any more severe that a few const_cast's here and there.

I appreciate that casting must be done judiciously. I also know that one can write C++ interfaces with the virtue of never requiring const-casting by clients at the cost of significant LOC increase.

You might worry that SQLite's [Pointer Passing Interface](https://sqlite.org/bindptr.html), given a non-const void *, is going to modify whatever it is that the pointer references. But if you read the carray code, you should be able to alleviate that worry for the pointer's final destination. As for its passage, I can assure you that the library code will not even dereference the pointer, let alone write through it. To the SQLite library, it is an opaque value which just happens to share the same sizeof with data pointers and has a "type" commonly used for data pointers because that is the C way of making/passing objects of that size.

That covers the pragmatic aspects of achieving the const-aesthetic you seek.

If you are a const purist, or seek to satisfy that crowd with nary a const_cast\<...\>() in sight, then I suppose you will need to expand that Pointer Passing Interface. You could even templatize it at the same time. It will be a thing of beauty, somewhat less Lite but highly pleasing to some who value that sort of thing.

(5) By Marco Bubke (marcob) on 2021-07-25 21:02:54 in reply to 4 [link]

Actually I care about undefined behaviour. I have seen already some quite nasty bugs because the compiler can do what ever it wants for UB. I thought it is the same for C. Personally I dislike discussions about code beauty. In my experience  people who love to discuss code beauty are similar unproductive like people who thinks tests are useless and spending 50% of your time debugging is normal. ;-)

Personally I think const as a contract in interfaces is a very useful information. So if somebody is doing a const cast and is changing the data...

And if you want to get philosophical we can exchange our thoughts about pragmatism as an ideology. But I think this is still preferable to the vulgar metaphysics many programmers use in their arguments. ;-)

I will follow your advise and patch carray.

(6) By Larry Brasfield (larrybr) on 2021-07-25 21:37:23 in reply to 5 [link]

> I care about undefined behaviour.

I have dealt with an architecture where a const pointer might have to be larger than a non-const pointer, but I do not think SQLite targets such. You could use a static assert to head off run-time trouble (or UB) of that nature.

> \[On code beauty and its discussion and aficionados ...\]

I apologize if I came too close to accusing you of anything along those lines. My main point was that one can go too far that way.

> \[On thought exchange and "preferable to the vulgar metaphysics" ...\]

I was cured of philosophy discussion very early in my college career. As a student of a philosopher who wrote, “A serious and good philosophical work could be written consisting entirely of jokes.”, (who is the only one I could take seriously), I am not so sure about "vulgar metaphysics". I think they might be the best kind.

(7) By Richard Damon (RichardDamon) on 2021-07-25 21:55:28 in reply to 6 [link]

It would be non-conforming for a const pointer to use a different representation than a non-const pointer.

6.2.5 p28 sentence 2 says "Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements." 

I could imagine a system that wants to do this, like a Harvard architecture to be able to specify code/data memories for const pointers, but the standard also allows ANY const pointer to be converted to a non-const pointer, and be fully usable as long as you don't actually write through it, so those platforms really need other solutions.

(8) By Larry Brasfield (larrybr) on 2021-07-25 23:07:06 in reply to 7 [link]

I was under the impression that code and data pointers could have differing sizeof. Are you saying otherwise (for conforming implementations?)

(9) By Richard Damon (RichardDamon) on 2021-07-25 23:12:23 in reply to 8 [link]

Pointers to functions and pointers to objects can be different, as can pointers to different types of objects, but const/non-const pointers to the same type of object have to be the same.

(10) By Keith Medcalf (kmedcalf) on 2021-07-26 00:14:58 in reply to 9 [link]

And here I thought the whole purpose of `const` as a keyword is "whining control".

(11) By Richard Hipp (drh) on 2021-07-26 02:21:50 in reply to 9 [link]

> Pointers to functions and pointers to objects can be different

They can be, but are they on any platform in common use today, or in the previous 20 years?

(12) By Scott Robison (casaderobison) on 2021-07-26 03:33:20 in reply to 11 [link]

In C, I don't think so. In C++, maybe / probably: [](https://stackoverflow.com/questions/16062651/about-sizeof-of-a-class-member-function-pointer)

(13) By Warren Young (wyoung) on 2021-07-26 03:45:05 in reply to 10 [link]

Much of [this excellent presentation](https://queue.acm.org/detail.cfm?id=3372264) is concerned with const-ness.

The bit about GCC “pure” functions is a promise of no side effects, approximately equivalent to SQLite’s “deterministic” UDF qualifier. The optimization depends on the compiler being able to prove that passed values will *remain* `const`.

The article also explains why SQLite’s amalgamation build is an effective optimization technique in absence of LTO in the compiler.

C++ takes it even further now with `constexpr`, but until someone forks a C++ only variant of SQLite permitting these optimizations, we’re getting off topic…

(14) By Richard Damon (RichardDamon) on 2021-07-26 04:33:15 in reply to 11 [link]

For 'Desktop' like systems, I don't think so, the last was probably 16 bit x86 (which some memory models had this characteristic), but there are embedded processors with Harvard Architectures with different size Function and Object pointers. I don't know if SQLite supports any of them.

Note, there ARE still machines out there running 32-bit windows which will still run 16-bit programs, so it can be a bit of a question of how you define 'platform in common use.

(15) By Marco Bubke (marcob) on 2021-07-26 07:51:26 in reply to 6 [link]

I call sentences like 'this is true', 'that is false', 'that makes sense' "vulgar metaphysics". Many Programmer like to use it all the time. It is very often a good sign you get conformation bias.

I prefer people who say 'I wrote a test and the values does not match. After some time I could pin it down to that function. After fixing it I wrote some more test to cover the cornercases.'
 
Many programmers love to use metaphysics and logic in a quite fundamentalistic way. I my experience this is not very productive. ;-)

(16) By Ryan Smith (cuz) on 2021-07-26 08:53:53 in reply to 15 [link]

> ...a good sign you get conformation bias.

My new favourite word for sheeple: People with "conformation bias". :)

(17) By Ryan Smith (cuz) on 2021-07-26 09:13:18 in reply to 15 [link]

On a more serious note, I get your sentiment with that reply, and as a Scientist I do like a healthy dollop of self-doubt dished up by people I trust.

I am however not grasping your idea fully, or to better explain - whilst claiming pure truth for everything in dispute is fundamentalism, saying "this is true" or "this is false" when it has been shown to be empirically so, is absolutely necessary, and ascribing variability to that which has none, is dishonest.

That is where you end up with people starting to talk about such things as "it is my truth" and "Nobody knows 100% for sure that gravity is real" or "I have made a version of bubble-sort that is quicker than Merge-sort".

In short, when it is so, there is nothing wrong with saying it is so, and when it isn't so, saying it is so on a public forum will (and should) produce exactly the kind of medicine that is needed to remedy such delusion.

One is always better off tackling/attacking the subject of what is said to be just so, rather than attacking the habit of saying things are just so, for the latter is doctrine and not argument.

(18) By Marco Bubke (marcob) on 2021-07-26 11:03:23 in reply to 17 [link]

I don't care if gravity is real. Real is a metaphysical word. ;-)

Gravity is useful.

I studied a little bit about metaphysics which in the common term often is described by a two world model of reality and perception. If you create two worlds you need words to connect them like 'true', 'false' and 'sense' etc.. Instead of them you can use words like knowledge, experience etc. which are practical very similar but still shows that they are context dependent even if their context is huge. This stop also people who like to argument that if you cannot show it's 100% true(which you never can if somebody is not stopping argumenting) it must be false(and for them useless). 

I don't mean anything goes. Empirical evidence shows that you cannot stand with one leg on the ground as your other legs tries to find ground on the other side of the cliff. You simply will fall. Sometimes this will take some time so you can tell everybody it is fine but ...