res2001

поднять галку "Запуск от имени Администратора"

во первых в этом случае запрос превышения прав будет всплывать каждый раз при запуске

Во вторых, правильно, создавать задачу в планировщике задач, там же и указывать условие запуска (можно без условия), и под каким пользователем, включая превышение прав.

Для запуска уже настроенной задачи без условия запуска можно использовать консольную команду schtasks /run

Да, есть: хранить сами изображения не БД, а в отдельном файловом хранилище с внешним доступом по ссылке-идентификатору. В самой же БД хранить только идентификаторы изображений в хранилище. Это стандартная практика работы с файлами и БД.

В библиотечных функциях - можно так сделать. В смысле, ваши функции используют непубличную функцию, передавая ей оператор.

Но вы этот оператор передаете всего в нескольких местах на всю кодовую базу и все. Писать так функции, которые вы используете кучу раз - очень плохая идея.

И вообще, довольно редко есть смысл так заморачиваться. Код становиться хуже поддерживаемый. Экономите вы совсем чуть чуть повторяемого кода. А потом придется всякие заморочки делать, вроде, в делении надо проверять на 0, а в умножении проверять на переполнение и т.д. Этот общий код становиться уже чуть ли не длиннее если все по отдельности делать. И уж точно хуже читаемый.

Поиграться в виртуалке, побеситься на тормоза.
Поставить в дуалбут Убунту, побеситься на экспериментальный десктоп.
Сменить ее на Минт и успокоиться в нормальном рабочем окружении.
Скорее всего, так.
Я предпочитаю Xubuntu, но ее все-таки надо под себя подпиливать.
Собственно, разницы-то в дистрибутивах для "инженера", который не собирается в них копаться, практически никакой. Берешь то, чем пользуется побольше народу, вот и весь выбор.

Вам надо не получить последовательность, а только определить значение элемента этой последовательности.
Запишем последовательность и пронумеруем её элементы с нуля. После этого переведём номера в двоичную систему и запишем их над элементами

Номера в десятичной системе:
00000000001111111111222222222233
01234567890123456789012345678901
Номера в двоичной системе:
00000000000000001111111111111111
00000000111111110000000011111111
00001111000011110000111100001111
00110011001100110011001100110011
01010101010101010101010101010101
Последовательность:
10010110011010010110100110010110

Можно заметить, что там, где двоичное представление содержит чётное количество битов, элемент последовательности равен 1, нечётное - 0.
Остаётся преобразовать номер в двоичную систему и посчитать количество битов. Надо учесть, какая нумерация используется в задании и, при необходимости, переводить её в нумерацию с нуля.

Разобрался.
Есть 2 замечания:
1. Поближе посмотрел на сигнатуру

bool __atomic_compare_exchange (type *ptr, type *expected, type *desired, bool weak, int success_memorder, int failure_memorder)

Короче говоря, мне нужно было передавать не указатели, а указатели на указатели. Исправил:

if (__atomic_compare_exchange(&l.head->next,  (struct entry**)NULL, &new_next, 1, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST))

Но потом начал ловить SEGFAULT. И тут пришел к 2 замечанию

2. Не заметил следующего в документации:

This built-in function implements an atomic compare and exchange operation. This compares the contents of *ptr with the contents of *expected. If equal, the operation is a read-modify-write operation that writes desired into *ptr. If they are not equal, the operation is a read and the current contents of *ptr are written into *expected. weak is true for weak compare_exchange, which may fail spuriously, and false for the strong variation, which never fails spuriously. Many targets only offer the strong variation and ignore the parameter. When in doubt, use the strong variation.

Т.е. если значение во 2 аргументе не равно значению из 1, то (!!!) по месту указателя 2 записывается полученное из указателя 1 значение. А у меня там был NULL (конец списка обозначается NULL). Заменил на корректно выделенный элемент списка и все заработало

int main(int argc, char const *argv[])
{
    struct list l;

    l.head = (struct entry *)malloc(sizeof(struct entry));
    l.head->next = NULL;
    l.head->value = 123;
    struct entry *old_next = (struct entry *)malloc(sizeof(struct entry));
    old_next->next = NULL;
    old_next->value = 555;
    l.head->next = old_next;

    struct entry *new_next = (struct entry *)malloc(sizeof(struct entry));
    new_next->value = 444;
    new_next->next = NULL;
    if (__atomic_compare_exchange(&l.head->next, &old_next, &new_next, 1, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST))
    {
        printf("ok\n");
        printf("success: next = %d\n", l.head->next->value);
    }
    else
    {
        printf("failed\n");
    }

    return 0;
}

Не хочу возиться со всякими dummy узлами, поэтому буду использовать __sync_bool_compare_and_swap. Вот такой код сработает:

int main(int argc, char const *argv[])
{
    struct list l;

    l.head = (struct entry *)malloc(sizeof(struct entry));
    l.head->next = NULL;
    l.head->value = 123;

    struct entry *new_next = (struct entry *)malloc(sizeof(struct entry));
    new_next->value = 444;
    new_next->next = NULL;

    if (__sync_bool_compare_and_swap(&l.head->next, (struct entry *)NULL, new_next))
    {
        printf("ok\n");
        printf("success: next = %d\n", l.head->next->value);
    }
    else
    {
        printf("failed\n");
    }

    return 0;
}

UPD: спасибо res2001, разобрался лучше. итоговый вариант

#include <stdatomic.h>

int main(int argc, char const *argv[])
{
    struct list l;

    l.head = (struct entry *)malloc(sizeof(struct entry));
    l.head->next = NULL;
    l.head->value = 123;

    struct entry *new_next = (struct entry *)malloc(sizeof(struct entry));
    new_next->value = 444;
    new_next->next = NULL;
    struct entry *tmp = NULL;
    if (atomic_compare_exchange_strong(&l.head->next, &tmp, new_next))
    {
        printf("ok\n");
        printf("success: next = %d\n", l.head->next->value);
    }
    else
    {
        printf("failed\n");
    }

    return 0;
}

Просто надо создать переменную указатель, которой присвоить NULL. Также использовал atomic_compare_exchange_strong из stdatomic вместо расширения GCC - он под капотом использует __atomic_* вместо устаревшего __sync_*

Нет, не увеличивается.

Как устранить ошибку конверсии при использовании битовых полей?

Не использовать битовые поля. Серьёзно. Удобств на копейку а мороки на рубль.

Репозиторий проекта - это не что-то стандартное. Авторы вольны применять любые процессы и скрипты для сборки. Может когда-то какой-нибудь ЧатЖПТ и сможет "прочитать" ридми ЛЮБОГО проекта и проделать всё необходимое для его сборки, но пока что такой инструмент мало реалистичен. Если разработчик сам не настроил CI/CD в проекте, то никак без него это сейчас не сделать.

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

Не создаётся. Но при изменении первичного индекса таблица полностью пересоздаётся с новым физическим порядком записей.

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

Представь такой (на самом деле невозможный, но не суть) случай - ты запросил таблицу. Вторая половина её ещё лежит в кэше, а первая уже выдавлена оттуда данными другой таблицы, нужными для выполнения запроса. Конечно, наиболее оптимальным будет начать передачу данных клиенту с этих записей, а пока они передаются, подчитать остальные, и передать их позже. Вот тебе порядок-то и поломался...

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

Похоже на какие-нибудь циклические инклуды.
У вас в data_process.h случайно не включается data_process.c?
Так делать не надо.

В C параметр функции не может быть массивом, только указателем. Синтаксис "имя с квадратными скобками" несёт тот же смысл, что и "имя со звёздочкой" когда речь идёт о параметрах функции. Если внутри функции взять sizeof от такого параметра результат будет равен sizeof от указателя. Это очень распространённая ошибка и компилятор говорит тебе об этом. Если тебе нужен размер массива переданного в функцию -- передавай его отдельно, например отдельным параметром.

sizeof(dict)/sizeof(const char)

Здесь ещё одна ошибка: dict -- это массив указателей (на самом деле указатель на такой массив, но по крайней мере, ты ожидал массив указателей), но ты делишь размер массива на размер const char а не на размер const char *. Во избежание таких ошибок для вычисления размера массива обычно пишут sizeof(dict)/sizeof(dict[0]).

Если записи фиксированного размера и отсортированы, а поиск идёт по префиксу, то никаких дополнительных структур не надо, достаточно двоичного поиска.