General Observations

Some of the functions return values that indicate success or failure, these values are never checked in the program where the functions are used.

There are a lot of possible bugs in this code.

The Function uint64_t to_uint64(const uint8_t *v)

There are a number of issues I see in this function, it could be simplified by calling a function that does a single 32 bit value in a loop. There is no masking of the values either on the left hand side or the right hand side. There are too many Magic Numbers (see below). It violates DRY programming (see below).

The Function int trigram_to_ui64(const wchar_t *v, uint64_t *ui64)

It isn't clear why the variable z is being allocated memory since a simple array would be easier to implement and the allocated memory never changes size.

    wchar_t z[3] = {0};

The variable z should not be declared until after the test:

    if ((WCHAR_MIN > 0) || (WCHAR_MAX < 0x10FFFF)) {
        fprintf(stderr, "Unprocessable rare UTF8 character. Found WCHAR_MIN=%d and WCHAR_MAX=%d", WCHAR_MIN, WCHAR_MAX);
        return 0;
    }

Let the Compiler Tell You Where Possible Issues Are

When doing C program development it is always a good practice to compile with the -Wall and -Wextra flags. These flags will help you find possible errors in the code. When I was learning how to program in C on Unix we had a program call lint which helped identify possible problems in the code. I always ran lint on my code. To some extent the -Wall and -Wextra flags have replaced lint.

If the program had been compile with the -Wall andd -Wextra flags it would have found the following issues:

/usr/bin/gcc-12   -g -Wall -Wextra -Werror -MD -MT CMakeFiles/zombie.dir/main.c.o -MF CMakeFiles/zombie.dir/main.c.o.d -o CMakeFiles/zombie.dir/main.c.o -c main.c
main.c: In function ‘trigram_to_ui64’:
main.c:64:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
   64 |     for (i = 0; i < wcslen(v); i++) {
      |                   ^
main.c:69:19: error: implicit declaration of function ‘count_bytes’ [-Werror=implicit-function-declaration]
   69 |             wc = (count_bytes(wc) > 3 ? 0x007f : wc);
      |                   ^~~~~~~~~~~
main.c: In function ‘main’:
main.c:115:9: error: unused variable ‘i’ [-Werror=unused-variable]
  115 |     int i;
      |         ^
main.c:96:14: error: unused parameter ‘argc’ [-Werror=unused-parameter]
   96 | int main(int argc, char **argv)
      |          ~~~~^~~~
main.c:96:27: error: unused parameter ‘argv’ [-Werror=unused-parameter]
   96 | int main(int argc, char **argv)
      |                    ~~~~~~~^~~~
cc1: all warnings being treated as errors

Declare the Variables as Needed

In the original version of C back in the 1970s and 1980s variables had to be declared at the top of the function. That is no longer the case, and a recommended programming practice to declare the variable as needed. In C the language doesn't provide a default initialization of the variable so variables should be initialized as part of the declaration. For readability and maintainability each variable should be declared and initialized on its own line.

Following this practice will also delete or remove the warning messages about unused variables.

For loop control variables should be declared in the for loop. Variables that are only used in the loop should be declared within the loop.

    for (const wchar_t **str = trigrams; *str; str++) {
        uint64_t ui64;
        wchar_t aux[3] = {0};
        printf("==> '%ls'\n", *str);

        /* Convert to uint64_t */
        trigram_to_ui64(*str, &ui64);

        /* Convert back to wchar_t string */
        ui64_to_trigram(ui64, aux);

        printf("<== '%ls': ", aux);
        if (wcscmp(*str, aux) == 0)
            printf("OK\n");
        else
            printf("NOT OK\n");
    }

Prefer Braces { and } Around Single Statements in if or loops

Some programmers consider this a style issue, but it makes it much easier to read and maintain the code if each in an if, else or loop block is embedded within braces. Extending the functionality of these statements can be problematic when the braces are not used. For a more in depth discussion of this see the first 2 answers on this Stack Overflow question. As one of the answers points out this is true in all C like languages (C, C++, C#, JavaScript, Java, etc.). I have worked at multiple companies where this was required in the coding standard and flagged during code reviews.

Magic Numbers

There are Magic Numbers through out the program, it would be better to create symbolic constants for them to make the code more readble and easier to maintain. These numbers may be used in many places and being able to change them by editing only one line makes maintainence easier.

Numeric constants in code are sometimes referred to as Magic Numbers, because there is no obvious meaning for them. There is a discussion of this on stackoverflow.

Some of the magic numbers:

        data[0] = (uint8_t)((wc >> 24) & 0xff);
        data[1] = (uint8_t)((wc >> 16) & 0xff);
        data[2] = (uint8_t)((wc >> 8) & 0xff);
        data[3] = (uint8_t)(wc & 0xff);

Test for Possible Memory Allocation Errors

In modern high-level languages such as C++, memory allocation errors throw an exception that the programmer can catch. This is not the case in the C programming language. While it is rare in modern computers because there is so much memory, memory allocation can fail, especially if the code is working in a limited memory application such as embedded control systems. In the C programming language when memory allocation fails, the functions malloc(), calloc() and realloc() return NULL. Referencing any memory address through a NULL pointer results in undefined behavior (UB).

Possible unknown behavior in this case can be a memory page error (in Unix this would be call Segmentation Violation), corrupted data in the program and in very old computers it could even cause the computer to reboot (corruption of the stack pointer).

To prevent this undefined behavior a best practice is to always follow the memory allocation statement with a test that the pointer that was returned is not NULL.

Convention When Using Memory Allocation in C

When using malloc(), calloc() or realloc() in C a common convention is to sizeof(*PTR) rather sizeof(PTR_TYPE), this make the code easier to maintain and less error prone, since less editing is required if the type of the pointer changes.

DRY Code

There is a programming principle called the Don't Repeat Yourself Principle sometimes referred to as DRY code. If you find yourself repeating the same code multiple times it is better to encapsulate it in a function. If it is possible to loop through the code that can reduce repetition as well.