jcmvbkbc

как это работает

Поскольку русский -- не часть ASCII, работает это по-разному в зависимости от кодировки. Если предположить, что исходник в UTF-8, то русские символы закодированы двумя байтами, а %c выводит только один. Если на одном выведенном байте остановиться -- получится фигня с вопросом. Но если вывести подряд все байты многобайтового символа -- получится этот символ.

как исправить

вариантов несколько. Самый простой -- выводить строки целиком. Если надо выводить посимвольно, можно узнавать количество байт в представлении одного символа функцией mblen, типа того:

#include <locale.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {
  char *a = "Привет, мир";
  int s;
  setlocale(LC_ALL, "");
  for (; *a != '\0'; a+=s) {
    s = mblen(a, strlen(a));
    printf("%.*s-", s, a);
    }
    return 0;
}

Здесь setlocale нужен для того, чтобы mblen понял, в какой кодировке символы на входе. Локаль в момент выполнения должна быть совместимой с кодировкой исходника в момент компиляции, если это условие не выполняется, работать будет неправильно.

Ещё вариант -- работать не с многобайтовой кодировкой а с wchar_t:

#include <locale.h>
#include <stdio.h>
#include <stddef.h>

int main() {
  wchar_t *a = L"Привет, мир";
  setlocale(LC_ALL, "");
  for (; *a != '\0'; a++) {
    printf("%lc-", *a);
    }
    return 0;
}

Здесь setlocale нужен для другого: он говорит внутренностям printf в какую локаль выполняется вывод чтобы в неё конвертировать wchar_t. Если локаль во время выполнения не будет соответствовать кодировке исходника, код всё равно будет работать.

При повторной итерации read, по идее, должен вернуть 0, так как все прочитано

Неа, не так это работает. 0 из read возвращается в одном единственном случае: если та сторона закрыла сокет на передачу и все посланные ею данные получены. В противном случае (сокет не закрыт) поведение зависит от настроек сокета: синхронный сокет при попытке чтения может заблокироваться в функции read или вернуть из неё -1 (и установить errno, например, в EINTR). Асинхронный сокет вернёт из read -1 и установит errno в EAGAIN или EWOULDBLOCK.
Ваш HTTP-сервер наверняка оставляет соединение открытым после того как прислал ответ на первый запрос, это можно понять по наличию заголовка Connection: Keep-Alive или отсутствию заголовка Connection: close в его ответе если это HTTP/1.1. Его можно попросить закрыть соединение после ответа, послав запрос с заголовком Connection: close или можно избежать блокировки в read прочитав только данные ответа размер которых прислан в заголовке ответа Content-Length.

Последняя кавычка ни в какую не хочет убираться, не могу понять, в чем дело

std::string variable_value = var.substr(variable_value_start + 1, variable_value_end - 1);

Второй параметр std::string::substr -- это длина выделяемой подстроки, а не индекс конца.
Должно быть

std::string variable_value = var.substr(variable_value_start + 1,
                                        variable_value_end - variable_value_start - 1);

Почему вместо строки появляется мусор?

size_t xpath_formatted_size = vsnprintf(NULL, 0, xpath, arguments);
  char* xpath_formatted = malloc(xpath_formatted_size);
  vsnprintf(xpath_formatted, xpath_formatted_size, xpath, arguments);

Потому что 1) результат возвращаемый vsnprintf не включает конечный 0, а вот аргумент vsnprintf обозначающий размер буфера должен включать место для конечного 0. И 2) вызов vsnprintf(…, arguments) меняет arguments.

Как это исправить?

Как-то так:

char* xpath_format(const char* xpath, ...)
{
  va_list arguments;
  va_start(arguments, xpath);

  size_t xpath_formatted_size = vsnprintf(NULL, 0, xpath, arguments) + 1;
  va_end(arguments);
  va_start(arguments, xpath);
  char* xpath_formatted = malloc(xpath_formatted_size);
  vsnprintf(xpath_formatted, xpath_formatted_size, xpath, arguments);

  va_end(arguments);
  return xpath_formatted;
}

Можно ли записать структуру в файл используя basic_ofstream?

Можно, но для этого не нужно делать её тип аргументом шаблона basic_ofstream.

Зачем он для такой строчки на 69, 70ой строчке добавляет к j такую странную константу.

В конечном коде выглядит действительно загадочно. Если вызывать компилятор с ключом -fdump-tree-all (фиг знает, как сделать это на godbolt.org, я проверял локально), то уже в самом первом дампе можно увидеть, что if (arr[j - 1] > arr[j]) превращается в это:

if (*(arr + ((sizetype) j + 1073741823) * 4) > *(arr + (sizetype) ((unsigned int) j * 4)))

1073741823 -- это 0x3fffffff, 30 единичных бит, т.е. 30-битная -1. Дальше j + 1073741823 превратилось в

add     r3, r3, #1073741824
subs    r3, r3, #1

т.е. в j + 1073741824 - 1. После умножения на 4 старшие два бита j теряются, но в чём смысл использования 30-битной -1 вместо 32-битной -- мне непонятно.
Поскольку константа появляется ещё до начала архитектурно-зависимых преобразований, она фигурирует в выводе для всех 32-битных архитектур поддерживаемых gcc. Интересно, что это началось между gcc-4.6 и gcc-5, до этого в этом месте генерировался просто sub r3, r3, #1. Ещё интересно, что даже с -O2 эта константа остаётся в сгенерированном коде, а исчезает только с -Os. Выглядит как регрессия.

В этом коде проблема не в том, что массив d не инициализирован, а в том, что колическтво итераций цикла вывода массива d не зависит от того, сколько элементов было занесено в этот массив. Правильным решением было бы как-то их связать, например так:

int i = 0, n;
while (piece != NULL)
{
    d[i] = piece;
    piece = strtok(NULL, " ");
    i++;
}
n = i;
for (i = 0; i < n; i++) {
    if(i%2==0)
        printf("%s ",d[i]);
}

ошибка возникает на моменте сдвига элементов. Как ее исправить?

data = (Student*)realloc(data, count * sizeof(Student));

    for (int i = count; i > offset; i--)
    {
        data[i] = data[i - 1];
    }

Этот код пишет за конец массива, потому что если в массиве count элементов, то последний имеет индекс count - 1. Этот цикл должен быть таким: for (int i = count - 1; i > offset; i--)

Почему при выполнение данной команды ОС продолжает работать до момента перезагрузки?

Я бы не сказал, что она "продолжает работать", но у нас, видимо, разные определения понятия "работать". Никакие новые исполняемые файлы в такой системе не могут быть запущены, потому что никаких файлов нет, а запущенные процессы -- да, могут продолжать выполняться и форкаться, пока им от файловой системы не нужны операции использующие имена файлов.
Ну и, справедливости ради, надо отметить, что место занятое открытыми на момент выполнения команды rm -rf / файлами не будет освобождено и их содержимое не будет потеряно, пока они не будут закрыты. Можно будет продолжать читать и писать в них, в т.ч. ядро будет продолжать использовать их для реализации механизмов виртуальной памяти.