jcmvbkbc

как выполнить задержку не понимаю

Для организации таймаута в liburing есть io_uring_prep_timeout, но кроме этого нужно сериализовать таймаут и все предыдущие команды (чтобы таймаут начинался после их окончания) и следующую после таймаута команду и сам таймаут (чтобы последующие команды не стартовали вместе с таймаутом). Сериализация делается установкой флага IOSQE_IO_DRAIN для sqe, почитать об этом можно например здесь. У меня нарисовался следующий пример, который записывает в файл (stderr), делает паузу в одну секунду, а потом записывает ещё:

#include <fcntl.h>
#include <liburing.h>
#include <stdio.h>
#include <sys/mman.h>

#define QUEUE_DEPTH 16

int main(int argc, char **argv)
{
        int i;
        struct io_uring ring;
        struct io_uring_cqe *pcqe;
        static const char msg0[] = "before timeout\n";
        static const char msg1[] = "after timeout\n";
        struct io_uring_sqe *sqe;

        io_uring_queue_init(QUEUE_DEPTH, &ring, 0);
        io_uring_prep_write(io_uring_get_sqe(&ring), 2, msg0, sizeof(msg0), 0);

        sqe = io_uring_get_sqe(&ring);
        io_uring_prep_timeout(sqe, (struct __kernel_timespec[]){{.tv_sec = 1}},
                              -1, IORING_TIMEOUT_ETIME_SUCCESS);
        io_uring_sqe_set_flags(sqe, IOSQE_IO_DRAIN);

        sqe = io_uring_get_sqe(&ring);
        io_uring_prep_write(sqe, 2, msg1, sizeof(msg1), 0);
        io_uring_sqe_set_flags(sqe, IOSQE_IO_DRAIN);
        io_uring_submit(&ring);
        for (i = 0; i < 3; ++i) {
                int rv = io_uring_wait_cqe(&ring, &pcqe);
                if (rv < 0) {
                        errno = -rv;
                        perror("io_uring_wait_cqe");
                } else {
                        io_uring_cqe_seen(&ring, pcqe);
                }
        }
}

как я могу это сделать?

Разносишь определения классов по файлам *.h. Разносишь определения методов классов по одноимённым файлам *.cc, инклудишь в них одноимённые *.h Потом смотришь на свою картинку. Стрелки наследования и агрегации добавляют include <файл в конце стрелки> в h файл в начале стрелки. Стрелки использования добавляют include <файл в конце стрелки> в cc файл в начале стрелки.

ONESTOPBIT ломало передачу блока

Передачу откуда куда?

DWORD ComIface::write(byte* data, int count)

Что конкретно эта функция должна делать? Если это просто запись count байтов, то зачем так сложно?

DWORD ComIface::read_block(byte* buffer, int size)

Что конкретно эта функция должна делать?

hpet rt;
    while (get_stats().cbInQue < size) {
        if (!SetCommMask(port_handle, EV_RXCHAR)) {
            printf("SetCommMask failed with error %d.\n", GetLastError());
            return NumberOfBytesRead;
        }
        WaitCommEvent(port_handle, &status, &overlap);
        WaitForSingleObject(overlap.hEvent, read_delay);
        if (rt.get_ms_dt_weak().count() > read_delay * size) {
            return NumberOfBytesRead;
        }
    }

Что здесь происходит?

Какие проблемы приводят к такому и как это чинить?

Чтобы что-то чинить нужно это сначала понять.

Твой traverse_loop держит указатель на текущую запись в eax, но первый же вызов PrintName портит почти все регистры и не восстанавливает их, поэтому первый же movzx esi, byte [eax + 10h] после этого вызова обращается мимо памяти и вызывает segfault. Проще всего это исправить каким-нибудь pusha / popa вокруг тела PrintName. После этого ты доберёшься до вызова PrintMark, где увидишь, что эта функция ожидает в eax + 10h текстового представления оценки, а у тебя пока есть только двоичное.

Шифрование происходит следующим образом:

Создается хеш ключа с помощью SHA512(его размер = 16 байт).
Для каждого из 16 блоков хеша создается случайное число с помощью Random, используя значение блока в качестве начального числа.
Создается массив байтов того же размера, что и ввод, и заполняется случайными числами.
Каждый байт ввода XOR-суммируется с соответствующим байтом массива байтов.

У этого алгоритма есть как минимум следующая уязвимость: если кто-то может получить пару "фрагмент открытого текста" - "соответствующий шифртекст" хотя бы для какого-нибудь открытого текста и заданного пароля, то он сможет расшифровать соответствующий фрагмент из любого текста зашифрованного с тем же паролем. Просто поксорив результат с известным фрагментом открытого текста и с соотвтетсвующим ему шифртекстом.

что я сделал не так, подскажите пожалуйста

if (b[i] >= x || b[i] <= y) {
  a[j] = b[i];
  j++;
}
...
if (b[i] < x || b[i] > y) {
  a[j] = b[i];
  j++;
}

Условия в операторах if не являются взаимоисключающими, а значит j может стать больше чем n и запись в a[j] вылезет за границу массива.
Я не уверен в правильности первого условия, но особо не задумываясь можно второе условие переписать как прямое отрицание первого: if (!(b[i] >= x || b[i] <= y)) и это гарантирует, что индекс не выйдет за пределы массива, вне зависимости от правильности первого условия.

Почему программы с одних адресов начинаются?

Потому что часть программ просто линкуется в одни и те же адреса. Это т.н. position-dependent executable, их в принципе невозможно загрузить для исполнения по другому адресу, и до недавнего времени (по крайней мере в linux) это было поведением по умолчанию. Но вот уже лет 10 во многих дистрибутивах по умолчанию используются PIE -- position-independent executables, и если не выключен ASLR, то при каждой загрузке часть адреса выбирается случайно. Но это сделано не для улучшения поведения TLB а для безопасности, поскольку это затрудняет атаки использующие известные адреса загрузки кода.

Вот есть Tlb, представим это как линейный массив, или c , если все адреса будут одинаковы. То Очевидно что tlb будет работать в 1% своего множества

Нет, не очевидно. Потому что никто не делает процессоры с пропорциональным отображением всего адресного пространства на все записи TLB. Обычно индексом записи TLB являются младшие биты номера страницы. Т.е. две соседние страницы могут использовать два соседних индекса в TLB, а канал TLB на 256 записей может быть полностью использован всего-то непрерывным мегабайтом памяти в 4-КБайтных страницах.

В svn было довольно удобно ориентироваться на последовательные номера редакций.

В git точно так же можно ориентироваться на вывод git describe, в котором присутствует ближайшая метка (или выбранная метка, если делать git describe --match 'mask'), количество коммитов после этой метки и хеш последнего коммита. Например, в одном и том же дереве linux я вижу:

$ git describe
xtensa-6.8-rc2-esp32-spi-8-gb25ff15921c2
$ git describe --match 'v*'
v6.8-rc2-52-gb25ff15921c2
$ git describe --match 'v?.?'
v6.7-13495-gb25ff15921c2

голова отстоит на 8 коммитов от последней метки xtensa-6.8-rc2-esp32-spi, или на 52 коммита от последней официальной метки v6.8-rc2 или на 13495 коммитов от последнего релиза v6.7.

считать количество русских букв, однако он не правильно это делает, что не так?

считать русские буквы сложно, твой код зависит от кодировки и в любой не-однобайтной кодировке этот код не будет работать правильно. Проще всего, мне кажется, выкинуть charVector и весь код связанный с ним, а оставшееся переписать следующим образом:

setlocale(LC_ALL, "");

const char *str = input.c_str();

while (*str) {
    wchar_t c;
    int n = mbtowc(&c, str, MB_CUR_MAX);

    if (n < 0)
        break;
    if (wcschr(L"абвгд...юя", c))
        ++count;
    str += n;
}