| 29 Apr 2026 |
 zoë (@blokyk) | * 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? | 15:13:45 |
| zoë (@blokyk) | * 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? | 15:13:52 |
| 30 Apr 2026 |
|  @deezrightwinger:matrix.org joined the room. | 01:21:10 |
| @deezrightwinger:matrix.org | Redacted or Malformed Event | 01:21:24 |
 electria | 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
| 01:27:31 |
|  @hxr404:tchncs.de left the room. | 13:43:59 |
 Qyriad | 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? Probably not. Iwrc there have been changes to Nixpkgs' default path mapping stuff since that commit, but if removing it now fixes things then yeet it! | 13:51:50 |
|  piegames banned @deezrightwinger:matrix.org (spam). | 18:33:21 |
|  isabel changed their profile picture. | 18:47:20 |
| 1 May 2026 |
 aloisw | Oh cool, I missed that when it came out: https://lwn.net/Articles/1054225/ | 11:19:40 |
| aloisw | It only took them almost seven years! | 11:19:49 |
 Sergei Zimmerman (xokdvium) | I thought it was an unmerged patchset? | 11:24:35 |
| aloisw | Not sure if it's the exact same API, but this looks like the entry point to the thing: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/io_uring/register.c?h=v7.0.3#n1014 | 11:26:15 |
| Sergei Zimmerman (xokdvium) | Oh great | 11:32:28 |
|  llakala set a profile picture. | 17:12:38 |
| 2 May 2026 |
| Sergei Zimmerman (xokdvium) | 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.
| 01:14:56 |
| aloisw | That's not my interpretation of "result of expressions involving strings with embedded NULs is undefined". To me it seems that storing or retrieving these strings is completely fine, but if you put it into a SQL expression the behaviour is unspecified in C standards language. | 05:10:20 |
| zoë (@blokyk) | 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.
| 07:25:16 |
| aloisw |
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". | 07:29:19 |
