I didn't know Lix had a Terms of Service (TOS), considering it's not a service...
A development chat is also most certainly not the right place for this

In reply to @blokyk:matrix.org
actually Qyriad i removed this line that you added in f9d08cc44c, and i do get correct sources in lldb and gdb without needing any setup in the debugger (eg source-map in lldb); is there some nuance i'm missing there?

Noticed one thing here:

https://git.lix.systems/lix-project/lix/src/commit/cd573beb0a60d6bf0e341bcd4d2c464ed97c1a8a/lix/libstore/sqlite.cc#L186-L190

The reasoning there doesn't seem entirely correct since per sqlite docs NUL bytes anywhere in the string are UB?

If a non-negative fourth parameter is provided to sqlite3_bind_text() or sqlite3_bind_text16() or sqlite3_bind_text64() then that parameter must be the byte offset where the NUL terminator would occur assuming the string were NUL terminated. If any NUL characters occur at byte offsets less than the value of the fourth parameter then the resulting string value will contain embedded NULs. The result of expressions involving strings with embedded NULs is undefined.

there's a docs page dedicated to this:

[...] The use of NUL within strings can lead to surprising behaviors:

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

The use of NUL characters in SQL text strings is not recommended.

This seems like a bug. But it is how SQLite works.

Lol, that's quite a formulation for "we didn't put the effort into making it work in the CLI".