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.

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

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;
}

В этом коде проблема не в том, что массив 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--)

Почему-то как я не стараюсь всё записывается только в sportsmens[i].full_name,

Поскольку ты используешь fscanf, а поля в твоём файле разделены пробелами, формат fscanf должен включать в себя пробелы чтобы избавиться от разделителей. Кроме того, имеет смысл проверить, что setlocale возвращает не-NULL, иначе он не повлияет на десятичный разделитель (и %f не сможет прочитать число с плавающей точкой записанное как 12,12).

Почему возникает ошибка

Из-за лишней звёздочки вот тут в функции input_array: scanf("%d", *(b+i));
Но и дальше пораскидано граблей: input_array выделяет память (b = (int*) malloc(a * sizeof(int));) и даже пытается её возращать, но неправильным типом и main это значение не использует. А поэтому в main b как был NULL так и остаётся. По-хорошему надо как-то так:

int * input_array(int a){
    int *b = (int*) malloc(a * sizeof(int));
    for (int i = 0; i < a; ++i) {
        printf("array[%d] = ", i);
        scanf(" %d", b+i);
    }
    return b;
}

int main() {
    ...
    printf("Введите длину массива:");
    scanf(" %d", &a);
    int *b = input_array(a);
    min = find_min(b, a);
    max = find_max(b,a);
    average = average_function(min, max);
    ...
}

гугля, находил предложения с LD_LIBRARY_PATH=... . Но разве флаг -L при компиляции не служит той же самой цели?

нет, не служит. -L говорит о том, где искать любые библиотеки во время линковки приложения. LD_LIBRARY_PATH говорит о том, где искать динамические библиотеки во время выполнения. Информация из -L со времени линковки нигде не сохраняется. Можно зашить в слинкованный бинарник пути к библиотекам, но это делается другими опциями (см. опцию линкера -rpath). Во время выполнения динамические библиотеки могут быть где угодно, не обязательно там, где они были во время линковки.

Как создать динамическую библиотеку, которая зависит от другой библиотеки?

вопрос, кстати, неправильный. Ты создал такую библиотеку. Если ты посмотришь в вывод readelf -d libwindow.so | grep NEEDED то там должна быть ссылка на libSDL. Твоя проблема в том, что сама libwindow.so не найдена.

char *str = malloc(0);
Правильно ли я понимаю, что в str находится начало выделянно памяти на 0 байт

Вот что говорит стандарт (c99, 7.20.3:1) о выделении 0 байт через malloc:

If the size of the space requested is zero, the behavior is implementation-
defined: either a null pointer is returned, or the behavior is as if the size were some
nonzero value, except that the returned pointer shall not be used to access an object.

Поскольку твоё обращение к этой памяти не вызывает SEGFAULT, то да, malloc вернул не NULL. Сколько байт реально было выделено зависит от реализации.

а дальше идет запись символов в память, которая для нас не предназначалась?

Да. Использовать эту память согласно стандарту нельзя.

Я пытаюсь загрузить 64-битное ядро по адресу 0x1000

Я вижу в этом коде три проблемы:
1. AllocatePages только возвращает адрес выделенной памяти по адресу в последнем параметре. Т.е. куда будут загружены сегменты ELF сказать нельзя и, соответственно, без динамической релокации этот ELF скорее всего работать не будет.
2. Нет гарантии, что между блоками памяти выделенными через AllocatePages будет то же расстояние, что и между сегментами ELF, в то время как кодогенерация с флагом -fPIE вполне может считать это расснояние неизменным. Такой ELF нужно загружать в один большой блок памяти, сохраняя расстояние между сегментами.
3. В следствие пункта 1 запуск ядра по адресу header.e_entry -- это прыжок в неизвестность.