Nul Characters in Strings in SQLite

Groxx

>* The length() SQL function only counts characters up to and excluding the first NUL.* > The quote() SQL function only shows characters up to and excluding the first NUL. > The .dump command in the CLI omits the first NUL character and all subsequent text in the SQL output that it generates. In fact, the CLI omits everything past the first NUL character in all contexts. That's just all kinds of "oh no", wow. I mean, I can't come up with a better strategy, but... oof. C-style strings being a thing at all really hurts.

DonHopkins

As long as we're supporting in-band signals in strings, how about making DEL rub out the previous character?

ventana

So, one fun consequence of this is that Unicode multi-byte strings (not UTF-8 but something like UTF-32) cannot be stored as strings in sqlite without a huge pain. Not that I ever planned to use multi-byte fixed length encodings, but good to know! A good moment to appreciate the elegance of UTF-8 which allowed to encode multi-byte characters preserving the semantics of C strings.

bruce511

Using this quirk allows for "hiding" data in the database. Because data after the nul is more-or-less invisible to generic dbBrowser type programs. If you suspect it is happening you can read it (by casting the SELECT as a BLOB, but obviously that's not a common pattern. Personally I've never done it, and clearly it's not something useful for security, but it does open the door to interesting meta-data storage opportunities. Again with the proviso that it is "untrustworthy".

adzm

So, it basically matches the behavior of a string in C, which can also have data in the allocation beyond the null terminator. I really don't see why this is a problem. It gives out exactly what you give it.