Most of the messages will have this value as NULL. Luckily, SQLite treats them as unique values.
It deserves at least warning level. We can't just silently not write message to log: the message might contain important information for user. The error also should be extremely rare and it should represent invalid state, so it makes sense to cons_show_error it to alert the user.
It would be better to use auto_gchar gchar* word instead of g_freeing it 2 lines below, because we would maintain consistency across the code (auto_-style), avoid risks of UAF in the future, and also match the type (g_strndup returns gchar*, not char*)
I am not sure right now, but I recall one XEP mentioning that we shouldn't trust by. Further investigation is required.
Literally WET. This parts repeats one-to-one with the part above. It deserves its own method. More than that,
segfaults_when_empty? Is it an actual behavior*? Or is it what we try to avoid? It's either a really strange test that expects undesired behavior or poor choice of a test name
This case doesn't test much :) Whether tab or shift+tab, we'll get file2.txt. We need at least 3 files to make an actual test.
We can add one more test for myuser@mydomain/user@laptop. As per RFC6122, section 2.4,
TODO: test with other popular messenger to ensure that this logic works correctly.
We already have a similar method. TODO: understand interaction of these 2 fixes.
How will it reflect on existing accounts? Would it be possible to have accounts with such names previously?
TODO: investigate double free/similar issues due to cleaning regardless of omemo_ctx.loaded. Likely, it's intentional, but I want to make sure. double free is worse than memleak