kttnr

page down behavior

2026-05-25T00:00:00+00:00

Page down could work better on the last page of content in web browsers in similar applications.

When reading content that doesn't fit on one page, I use the page down key to get to the next visual page. Page down scrolls down so that what was previously at the bottom of the screen goes to the top. I immediately know where to place my eyes to continue reading.

This breaks near the end of the content. If there is only half a screen worth of content left, then page down reaches the end of the article and the next line of content ends up in the middle of the screen instead of the top. I don't know that this is the last page or how much content is left. I don't know where to place my eyes. I have to scan the whole page top to bottom to find where I left off. This is annoying.

I wish page down had the same behavior on the last page as it does on the previous pages. Applications could implement this by adding an extra screen's worth of space at the end of the content. This would also allow manually scrolling there. I sometimes want this to place something higher on the screen without moving the application window.

The new behavior should not apply to the end key, which scrolls to the end of a page. That should continue to work as before, placing the end of the content at the bottom of the screen.

sandboxing Wayland applications

2026-05-15T00:00:00+00:00

I like sandboxing Linux applications. Tools like bubblewrap</a> and Bubblejail</a> make this easy, building on Linux namespaces</a>.

This works well for command line applications, but sandboxing graphical applications is harder. A graphical Wayland application needs to access the Wayland socket to handle its windows. The Wayland socket gives access to sensitive data like screen contents. You might want to restrict this. With the security_context</a> protocol, you can.

Instead of mounting the normal Wayland socket into the sandbox, mount a socket that has the security context applied. You can create such a socket with way-secure</a>. This makes Wayland applications work safely.

I mainly wanted to write about the Wayland socket in this post because there isn't much awareness of the bubblewrap plus way-secure approach. The Wayland socket is not everything. The application can show a window, but other desktop application features are missing. This is the same problem that Flatpak</a> solves with tools like XDG Desktop Portal</a>. See what Flatpak permissions are available here</a>. You can reuse some of the Flatpak tools and approaches. Bubblejail does this to some degree but needs more polish.

Firefox tracking protection Google whitelist

2025-09-29T00:00:00+00:00

Some Firefox configuration strings give the incorrect impression that Firefox excludes Google from tracking protection. These strings and their explanation are difficult to find through internet search. This article is that explanation.

Firefox has built in tracking protection with configuration in about:config</code>. Some of the config keys contain "whitelist":


urlclassifier.features.fingerprinting.annotate.whitelistTables</code></li>
urlclassifier.features.fingerprinting.whitelistTables</code></li>
urlclassifier.features.socialtracking.annotate.whitelistTables</code></li>
urlclassifier.features.socialtracking.whitelistTables</code></li>
urlclassifier.trackingAnnotationWhitelistTable</code></li>

urlclassifier.trackingWhitelistTable</code></li> </ul> The keys store a list with these elements:
- google-trackwhite-digest256</code></li> </ul> This gives the incorrect impression that Firefox excludes Google from tracking protection. Firefox loads the tracking protection database at runtime. One part of the database stores which URLs to block. Another part stores a list of exceptions when not to block. This is the "whitelist". It exists because it doesn't make sense to block a tracking domain in all circumstances. You want to block tracking domains embedded on other domains. For example, on my-personal-blog.com</code> you want to block tracker.evilcorp.com</code>. But on the main evilcorp.com</code> it doesn't make sense to block the tracking subdomain. The same company controls both domains and can already track you through the domain main. The tracking subdomain doesn't add any extra tracking capabilities. Additionally, blocking tracking subdomains often breaks the main website. Firefox used to have only one whitelist called mozstd-trackwhite</code>. At some point they added many Google domains to it. This made the it grow in size significantly which triggered a bug in the code that loads it. As a workaround they separated the new domains into another list called google-trackwhite</code>. The list is not made by Google. The list does not favor Google. The list just contains a subset of the changes intended for the main list. In the future Firefox might merge the lists again. The whitelist configuration is not evidence of Firefox favoring Google. Sources:



Rust HashMap limitations
2024-12-16T00:00:00+00:00
This post gives examples of API limitations in the Rust standard library's HashMap</code></a>. The limitations make some code slower than necessary. The limitations are on the API level. You don't need to change much implementation code to fix them but you need to change stable standard library APIs.</p>
entry</h2>
HashMap has an entry API</a>. Its purpose is to allow you to operate on a key in the map multiple times while looking up the key only once. Without this API, you would need to look up the key for each operation, which is slow.</p>
Here is an example of an operation without the entry API:</p>
fn insert_or_increment(key: String, hashmap: &mut HashMap<String, u32>) {
    if let Some(stored_value) = hashmap.get_mut(&key) {
        *stored_value += 1;
    } else {
        hashmap.insert(key, 1);
    }
}
</code></pre>
This operation looks up the key twice. First in get_mut</code>, then in insert</code>.</p>
Here is the equivalent code with the entry API:</p>
fn insert_or_increment(key: String, hashmap: &mut HashMap<String, u32>) {
    hashmap
        .entry(key)
        .and_modify(|value| *value += 1)
        .or_insert(1);
}
</code></pre>
This operation looks up the key once in entry</code>.</p>
Unfortunately, the entry API has a limitation. It takes the key by value. It does this because when you insert a new entry, the hash table needs to take ownership of the key. However, you might not always decide to insert a new entry after seeing the existing entry. In the example above we only insert if there is no existing entry. This matters when you have a reference to the key and turning it into an owned value is expensive.</p>
Consider this modification of the previous example. We now take the key as a string reference rather than a string value:</p>
fn insert_or_increment(key: &str, hashmap: &mut HashMap<String, u32>) {
    hashmap
        .entry(key.to_owned())
        .and_modify(|value| *value += 1)
        .or_insert(1);
}
</code></pre>
We had to change entry(key)</code> to entry(key.to_owned())</code>, cloning the string. This is expensive. It would be better if we only cloned the string in the or_insert</code> case. We can accomplish by not using the entry API like in this modification of the first example.</p>
fn insert_or_increment(key: &str, hashmap: &mut HashMap<String, u32>) {
    if let Some(stored_value) = hashmap.get_mut(key) {
        *stored_value += 1;
    } else {
        hashmap.insert(key.to_owned(), 1);
    }
}
</code></pre>
But now we cannot get the benefit of the entry API. We have to pick between two inefficiencies.</p>
This problem could be avoided if the entry API supported taking the key by reference (more accurately: by borrow) or by Cow</code></a>. The entry API could then internally use to_owned</code> when necessary.</p>
The custom hash table implementation in the hashbrown crate implements</a> this improvement. Here</a> is a post from 2015 by Gankra that goes into more detail on why the standard library did not do this.</p>
Borrow</h2>
The various HashMap functions</a> that look up keys do not take a reference to the key type. Their signature looks like this:</p>
pub fn contains_key<Q>(&self, k: &Q) -> bool
where
    K: Borrow<Q>,
    Q: Hash + Eq + ?Sized,
</code></pre>
They take a type Q, which the hash table's key type can be borrowed as. This happens through the borrow</a> trait. This makes keys more flexible and allows code to be more efficient. For example, String</code> as the key type still allows look up by &str</code> in addition of &String</code>. This is good because it is expensive to turn &str</code> into &String</code>. You can only do this by cloning the string. Generic keys through the borrow trait allow us to work with &str</code> directly, omitting the clone.</p>
Unfortunately the borrow API has a limitation. It is impossible to implement in some cases.</p>
Consider the following example, which uses a custom key type:</p>
#[derive(Eq, PartialEq, Hash)]
struct Key {
    a: String,
    b: String,
}

type MyHashMap = HashMap<Key, ()>;

fn contains_key(key: &Key, hashmap: &MyHashMap) -> bool {
    hashmap.contains_key(key)
}
</code></pre>
Now consider a function that takes two key strings individually by reference, instead of the whole key struct by reference:</p>
fn contains_key(key_a: &str, key_b: &str, hashmap: &MyHashMap) -> bool {
    todo!()
}
</code></pre>
How do we implement the function body? We want to avoid expensive clones of the input strings. It seems like this is what the borrow trait is made for. Let's create a wrapper struct that represents a custom key reference. The struct functions &str</code> instead of &String</code>.</p>
#[derive(Eq, PartialEq, Hash)]
struct KeyRef<'a> {
    a: &'a str,
    b: &'a str,
}

impl<'a> Borrow<KeyRef<'a>> for Key {
    fn borrow(&self) -> &KeyRef<'a> {
        &KeyRef {
            a: &self.a,
            b: &self.b,
        }
    }
}

fn contains_key(key_a: &str, key_b: &str, hashmap: &MyHashMap) -> bool {
    let key_ref = KeyRef { a: key_a, b: key_b };
    hashmap.contains_key(&key_ref)
}
</code></pre>
This does not compile. In the borrow function we attempt to return a reference to a local value. This is a lifetime error. The local value would go out of scope when the function returns, making the reference invalid. We cannot fix this. The borrow trait requires returning a reference. We cannot return a value. This is fine for String</code> to &str</code> or Vec<u8></code> to &[u8]</code>, but it does not work for our key type.</p>
This problem could be avoided by changing the borrow trait or introducing a new trait for this purpose.</p>
(In the specific example above, we could workaround this limitation by changing our key type to store Cow<str></code> instead of String</code>. This is worse than the KeyRef</code> solution because it is slower because now all of our keys are enums. A more efficient, more boilerplate workaround is using &dyn</code> trait objects as documented</a> by user sunshowers.)</p>
The custom hash table implementation in the hashbrown crate implements this improvement. Hashbrown uses a better designed custom trait</a> instead of the standard borrow trait.</p>


fast float to integer conversions
2024-11-10T00:00:00+00:00
In Rust, the standard way of converting floating point values to integers is with the as</code> operator</a>. This conversion has various guarantees as listed in the reference. One of them is that it saturates: Input values out of range of the output type convert to the minimal/maximal value of the output type.</p>
assert_eq!(300f32 as u8, 255);
assert_eq!(-5f32 as u8, 0);
</code></pre>
Saturation comes with a downside. It is slower than not saturating. In C/C++ this kind of cast is undefined behavior</a>. Rust's casts are never undefined behavior (good), but they are slower than C/C++.</p>
On many hardware targets</a> a float to integer conversion can be done in one instruction. For example CVTTSS2SI</code></a> on x86_84+SSE. This is the minimum amount of work we need to do to perform the conversion. This is what the C/C++ cast compiles to. Rust needs more instructions because of the additional guarantees.</p>
Sometimes you want faster conversions and don't need saturation. You might already know that your inputs are in range or you might not care about the result for out of range inputs. My new fast-float-to-integer crate</a> provides this. If in range, then the conversion functions work like the standard as</code> operator conversion. If not in range, then you get an unspecified value. We get the speed of the C/C++ version without the undefined behavior.</p>
You never get undefined behavior but you can get unspecified behavior. In the unspecified case, you get an arbitrary value. The function returns and you get a valid value of the output type, but there is no guarantee what that value is. On the assembly level the result is specified but we cannot guarantee this in the crate because the behavior varies between platforms.</p>
assembly</h2>
We keep track of the generated assembly in the repository and enforce on CI that it is up to date. Here is a typical assembly comparison on x86_64+SSE.</p>
standard:</p>
f32_to_i64:
    cvttss2si rax, xmm0
    ucomiss xmm0, dword ptr [rip + .L_0]
    movabs rcx, 9223372036854775807
    cmovbe rcx, rax
    xor eax, eax
    ucomiss xmm0, xmm0
    cmovnp rax, rcx
    ret
</code></pre>
fast:</p>
f32_to_i64:
    cvttss2si rax, xmm0
    ret
</code></pre>
As expected, we do the conversion in one instruction. The extra assembly in the standard version performs the saturation.</p>
A more complicated case is f32 to u64. We cannot handle this in one instruction, because the cvttss2si instruction outputs an i64. It cannot handle the values between i64::MAX</code> and u64::MAX</code>. (AVX512 could do this, but the intrinsics are not stable and it might not be faster.) With some clever optimization, we can still do better than the standard version. I copied the following Rust code from the repository</a>.</p>
standard:</p>
f32_to_u64:
    cvttss2si rax, xmm0
    mov rcx, rax
    sar rcx, 63
    movaps xmm1, xmm0
    subss xmm1, dword ptr [rip + .L_0]
    cvttss2si rdx, xmm1
    and rdx, rcx
    or rdx, rax
    xor ecx, ecx
    xorps xmm1, xmm1
    ucomiss xmm0, xmm1
    cmovae rcx, rdx
    ucomiss xmm0, dword ptr [rip + .L_1]
    mov rax, -1
    cmovbe rax, rcx
    ret
</code></pre>
fast:</p>
f32_to_u64:
    cvttss2si rcx, xmm0
    addss xmm0, dword ptr [rip + .L_0]
    cvttss2si rdx, xmm0
    mov rax, rcx
    sar rax, 63
    and rax, rdx
    or rax, rcx
    ret
</code></pre>
First, let us consider a relatively naive branchful solution:</p>
#[inline(always)]
fn _f32_to_u64_branchful(float: f32) -> u64 {
    const THRESHOLD_FLOAT: f32 = power_of_two_f32(63);
    const THRESHOLD_INTEGER: u64 = 2u64.pow(63);

    let in_range = float <= THRESHOLD_FLOAT;
    if in_range {
        f32_to_i64(float) as u64
    } else {
        // Subtract the threshold from the float. The result is >= 0 because the input is larger
        // than the subtrahend. The result is <= i64::MAX because `u64::MAX - i64::MAX == i64::MAX`.
        let in_range_float = float - THRESHOLD_FLOAT;
        let integer = f32_to_i64(in_range_float) as u64;
        // Overflow is benign because it can only occur for invalid inputs.
        integer.overflowing_add(THRESHOLD_INTEGER).0
    }
}
</code></pre>
We can turn this into a less naive branchless solution:</p>
#[inline(always)]
fn f32_to_u64_branchless(float: f32) -> u64 {
    const THRESHOLD: f32 = power_of_two_f32(63);

    let integer1 = f32_to_i64(float);
    let integer2 = f32_to_i64(float - THRESHOLD);
    // If the input is larger than i64::MAX, then integer1 is i64::MIN. This value has 1 as the
    // leftmost bit and 0 as the remaining bits. Right shift on signed values is arithmetic, not
    // logical [1]. We end up with all 0 (in range) or all 1 (out of range).
    let too_large = integer1 >> 63;
    // # If the input is not too large:
    //
    // Integer1 has the correct value. The mask is all 0, which makes the Or result in integer1.
    //
    // # If the input is too large:
    //
    // Integer1 is i64::MIN and the mask is all 1. The Or results in `i64::MIN | integer2`.
    // integer2 has the correct result minus 2**63. This is the correct result without the
    // leftmost bit. The Or adds the missing leftmost bit back.
    (integer1 | (integer2 & too_large)) as u64
}
</code></pre>
This compiles to the assembly above.</p>


missed Rust optimizations
2023-07-14T00:00:00+00:00
I like inspecting the optimized assembly instructions of small self contained parts of my Rust programs. I sometimes find code that doesn't optimize well. This is especially interesting when it is possible to rewrite the code in a semantically equivalent way which optimizes better. I want to give some examples of this as evidence that it can be worth it to try to improve generated assembly. Compilers are neither perfect nor always better than humans.</p>
The presented examples all come from real code that I wrote. They are not contrived. You can find more examples in the Rust issue tracker with the "slow" label</a>.</p>
cargo-show-asm</a> and Compiler Explorer</a> work well for looking at Rust compiler output.</p>
example one</h2>
Compiler Explorer</a>, Rust issue</a></p>
We have a simple enum on which we want to implement an iterator style next</code> function.</p>
#[derive(Clone, Copy)]
enum E {
    E0,
    E1,
    E2,
    E3,
}
</code></pre>
You might implement next</code> like this:</p>
fn next_v0(e: E) -> Option<E> {
    Some(match e {
        E::E0 => E::E1,
        E::E1 => E::E2,
        E::E2 => E::E3,
        E::E3 => return None,
    })
}
</code></pre>
Which produces this assembly:</p>
example::next_v0:
        mov     al, 4
        mov     cl, 1
        movzx   edx, dil
        lea     rsi, [rip + .LJTI0_0]
        movsxd  rdx, dword ptr [rsi + 4*rdx]
        add     rdx, rsi
        jmp     rdx
.LBB0_2:
        mov     cl, 2
        jmp     .LBB0_3
.LBB0_1:
        mov     cl, 3
.LBB0_3:
        mov     eax, ecx
.LBB0_4:
        ret
.LJTI0_0:
        .long   .LBB0_3-.LJTI0_0
        .long   .LBB0_2-.LJTI0_0
        .long   .LBB0_1-.LJTI0_0
        .long   .LBB0_4-.LJTI0_0
</code></pre>
The match expression turns into a jump table with 4 branches. You would expect this assembly, if we did some arbitrary operation in each match case, that isn't related to the other cases. However, If you are familiar with how Rust represents enums and options, you might realize that this is not optimal.</p>
The enum is 1 byte large. The variants are represented as 0, 1, 2, 3. This representation is not guaranteed (unless you use the repr</code> attribute) but it is how enums are represented today. The enum only uses 4 out of the 256 possible values. To save space in Option</code>s the Rust compiler performs "niche optimization". An option needs one more pattern to represent the empty case None</code>. If the inner type has a a free variant, the niche, then it can be used for that. In fact, the representation of Option::<E>::None</code> is 4. To implement next</code> we just need to increment the byte.</p>
Unfortunately the compiler does not realize this unless we rewrite the function like this:</p>
fn next_v1(e: E) -> Option<E> {
    match e {
        E::E0 => Some(E::E1),
        E::E1 => Some(E::E2),
        E::E2 => Some(E::E3),
        E::E3 => None,
    }
}
</code></pre>
Which produces this assembly:</p>
example::next_v1:
        lea     eax, [rdi + 1]
        ret
</code></pre>
This is better. There are only two instructions and no branches.</p>
example two</h2>
Compiler Explorer</a>, Rust issue</a></p>
We have an array of 5 boolean values and want to return whether all of them are true.</p>
pub fn iter_all(a: [bool; 5]) -> bool {
    a.iter().all(|s| *s)
}

pub fn iter_fold(a: [bool; 5]) -> bool {
    a.iter().fold(true, |acc, i| acc & i)
}

pub fn manual_loop(a: [bool; 5]) -> bool {
    let mut b = true;
    for a in a {
        b &= a;
    }
    b
}
</code></pre>
iter_all</code>, iter_fold</code>, manual_loop</code> produce the same assembly:</p>
example::iter_all:
        movabs  rax, 1099511627775
        and     rax, rdi
        test    dil, dil
        setne   cl
        test    edi, 65280
        setne   dl
        and     dl, cl
        test    edi, 16711680
        setne   cl
        test    edi, -16777216
        setne   sil
        and     sil, cl
        and     sil, dl
        mov     ecx, 4278190080
        or      rcx, 16777215
        cmp     rax, rcx
        seta    al
        and     al, sil
        ret
</code></pre>
Usually when several functions have the same assembly they are merged together. This not happening might indicate that the compiler did not understand that all of them do the same thing.</p>
The assembly is an unrolled version of the iterator or loop. Note that the integer constants mask out some bits from a larger pattern like 0xFF00... There is a comparison for every bool. This feels suboptimal because all booleans being true has a single fixed byte pattern that we could compare against together. I try to get the compiler to understand this:</p>
pub fn comparison(a: [bool; 5]) -> bool {
    a == [true; 5]
}

pub fn and(a: [bool; 5]) -> bool {
    a[0] & a[1] & a[2] & a[3] & a[4]
}
</code></pre>
example::comparison:
        movabs  rax, 1099511627775
        and     rax, rdi
        movabs  rcx, 4311810305
        cmp     rax, rcx
        sete    al
        ret

example::and:
        not     rdi
        movabs  rax, 4311810305
        test    rdi, rax
        sete    al
        ret
</code></pre>
This is better. I'm not sure if and</code> is optimal but it is the best version so far.</p>
caveats</h2>
When I say that some code doesn't optimize well or that some assembly is better, I mean that the code could be compiled into assembly that does the same thing in less time. If you are familiar with assembly, this can be intuited by looking at it. However, the quality of the assembly is not just a product of the instructions. It depends on other things like what CPU you have and what else is going on in the program. You need realistic benchmarks to determine whether some code is faster with high confidence. You might also care less about speed and more about the size of the resulting binary. These nuances do not matter for the examples in this post.</p>
While I was able to rewrite code to improve generated assembly, none of the improvements are guaranteed. With the next compiler version both versions of the code might compile to the same assembly. Or the better version today might become the worse version tomorrow. This is an argument in favor of not worrying too much about the generated assembly and more about other metrics like code clarity. Still, for especially hot loops or especially bad assembly, making these adjustments can be worth it.</p>


null terminated strings are incorrect
2022-11-25T00:00:00+00:00
introduction</h2>
In the C programming language it is common to store text as null terminated strings. A null terminated string is a sequence of bytes ending in a null byte (0x00</code>, more than one byte for wide characters) that represents a sequence of characters in some text encoding. Each character is mapped to one or more bytes according to the encoding.</p>
C defines the following string types:</p>

byte</a>, example ASCII</li>
multibyte</a>, example UTF-8</li>
wide</a>, example UTF-32</li>
</ul>
All of them are null terminated. Each comes with syntax for creating literals</a> in source code, and functions that operate on them like strcpy</code></a>.</p>
For example, the literal "hello"</code> is a null terminated byte string represented in memory as 0x68 0x65 0x6c 0x6c 0x6f 0x00</code>. The first 5 bytes come from the ASCII</a> encoding. The next and last byte is the null byte. It doesn't correspond to any character in the original text. It only indicates the end of the string.</p>
problem</h2>
Intuitively a programming language is expected to handle any string in the active encoding. It would be surprising if hello world</code> was an acceptable string while hello earth</code> was not.</p>
C violates this expectation. It does so because it gives special meaning to the null byte. Encodings like ASCII and UTF-8 already assign meaning to the null byte. It encodes the null character</a>. What exactly the null character means is not relevant. It only matters that it is a valid character and encoded as 0x00</code>. This meaning clashes with the meaning C gives the null byte. A string supposed to contain the null character is instead cut short at its position.</p>
For example, hello\0world</code> (\0</code> is the null character) is a valid ASCII and UTF-8 string that could be a literal in source code or read from a file. It can even be typed on the right kind of keyboard, just like pressing the enter key types the newline \n</code> character. But the string functions in the C standard library cannot handle the null character correctly because they treat it as the end of the string like in the following examples:</p>

strcpy</code> only copies hello</code>.</li>
strcmp</code> returns that hello\0world</code> and hello\0earth</code> are equal.</li>
printf</code> only prints hello</code>.</li>
</ul>
This is not a bug in these functions. It is a fault in the C standard for designing the string types with null termination.</p>
solution</h2>
An alternative way to represent strings is with a pointer and a size. This is done in C++'s std::string</code>, std::string_view</code> and other languages. This representation does not have C's problem and has other technical benefits unrelated to correctness that this post does not go into.</p>
A historical reason that C chose the null byte representation is that it saves memory. Only one extra byte is needed. This is no longer a good reason and maybe was not one even then. The gain in efficiency is not worth the loss in correctness.</p>
Use better string types. Do not use C's null terminated string functions. Use libraries that handle strings correctly.</strong></p>
I would like to link a C library that replicates the standard library's string functions with pointer and size but I do not know one.</p>
You can store string literals containing null bytes in arrays with const char text[] = "hello\0world";</code>. This gives you access to the size of the string where a pointer would not. The ending null byte is still added.</p>
examples of problematic software</h2>
SQLite</h3>
SQLite states</a> its string type stores UTF-8. This is incorrect because SQLite uses null terminated strings. See documentation</a> stating strings containing null bytes are undefined behavior. In practice they don't cause errors but are sometimes silently cut off.</p>

documentation quote</summary>

In those routines that have a fourth argument, its value is the number of bytes in the parameter. To be clear: the value is the number of bytes in the value, not the number of characters. If the fourth parameter to sqlite3_bind_text() or sqlite3_bind_text16() is negative, then the length of the string is the number of bytes up to the first zero terminator. If the fourth parameter to sqlite3_bind_blob() is negative, then the behavior is undefined. 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.</p>
</blockquote>
</details>

program demonstrating null byte behavior</summary>
// Compile with `-std=C23`.

#include <assert.h>
#include <stdio.h>

#include "sqlite3.h"

int main() {
    sqlite3* db = nullptr;
    int result = 0;
    sqlite3_stmt* statement;

    const char* data = "first\0second";
    const int data_len = 13;

    result = sqlite3_open_v2(
        "a",
        &db,
        SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE | SQLITE_OPEN_MEMORY,
        nullptr
    );
    assert(result == SQLITE_OK);

    result = sqlite3_exec(
        db,
        "CREATE TABLE table_(text TEXT, blob BLOB);",
        nullptr,
        nullptr,
        nullptr
    );
    assert(result == SQLITE_OK);

    result = sqlite3_prepare_v3(
        db,
        "INSERT INTO table_(text, blob) VALUES (?1, ?2);",
        -1,
        0,
        &statement,
        nullptr
    );
    assert(result == SQLITE_OK);
    result = sqlite3_bind_text(statement, 1, data, data_len, SQLITE_STATIC);
    assert(result == SQLITE_OK);
    result = sqlite3_bind_blob(statement, 2, data, data_len, SQLITE_STATIC);
    assert(result == SQLITE_OK);
    result = sqlite3_step(statement);
    assert(result == SQLITE_DONE);
    result = sqlite3_finalize(statement);
    assert(result == SQLITE_OK);

    result = sqlite3_prepare_v3(
        db,
        "SELECT text, blob FROM table_;",
        -1,
        0,
        &statement,
        nullptr
    );
    assert(result == SQLITE_OK);
    result = sqlite3_step(statement);
    assert(result == SQLITE_ROW);
    const int text_size = sqlite3_column_bytes(statement, 0);
    const int blob_size = sqlite3_column_bytes(statement, 1);
    result = sqlite3_finalize(statement);
    assert(result == SQLITE_OK);

    result = sqlite3_prepare_v3(
        db,
        "SELECT CAST(text as BLOB), CAST(blob as TEXT) FROM table_;",
        -1,
        0,
        &statement,
        nullptr
    );
    assert(result == SQLITE_OK);
    result = sqlite3_step(statement);
    assert(result == SQLITE_ROW);
    const int text_as_blob_size = sqlite3_column_bytes(statement, 0);
    const int blob_as_text_size = sqlite3_column_bytes(statement, 1);
    result = sqlite3_finalize(statement);
    assert(result == SQLITE_OK);

    result = sqlite3_prepare_v3(
        db,
        "SELECT text FROM table_ WHERE text LIKE '%second%';",
        -1,
        0,
        &statement,
        nullptr
    );
    assert(result == SQLITE_OK);
    result = sqlite3_step(statement);
    assert(result == SQLITE_ROW | result == SQLITE_DONE);
    const bool found_string = result == SQLITE_ROW;
    result = sqlite3_finalize(statement);
    assert(result == SQLITE_OK);

    result = sqlite3_close_v2(db);
    assert(result == SQLITE_OK);

    printf("text size: %i\n", text_size);
    printf("blob size: %i\n", blob_size);
    printf("text as blob size: %i\n", text_as_blob_size);
    printf("blob as text size: %i\n", blob_as_text_size);
    printf("found string: %i\n", found_string);
}

/*
possible output:

text size: 13
blob size: 13
text as blob size: 13
blob as text size: 13
found string: 0
*/


</code></pre>
</details>
Postgres</h3>
PostgreSQL states</a> its string type can store UTF-8. This is incorrect because Postgres uses null terminated strings. This is handled better than in SQLite because Postgres documents</a> (search for NUL</code>) the restriction and errors when a string containing a null byte would be used.</p>