Как загружатся с squashfs образа?

интересно узнать, как взрослые мальчики типо archlinux или debian пакуют свой root в squashfs образ, а точнее, как с него загружаются

а что мешает-то? Бери livecd и смотри что происходит.

Есть ли способ быстро выравнивать адреса?

addr = (addr | (alignment - 1)) + 1;

res2001, увеличивает адрес, даже если он уже был выровнен.

Есть ли способ быстро выравнивать адреса?

Герман, 2^x = 1 << x

Есть ли способ быстро выравнивать адреса?

Герман, я не знаю ничего быстрее чем вариации на тему 1ul << (sizeof(addr) * 8 - clz(addr))

Есть ли способ быстро выравнивать адреса?

Герман, да точно так же: addr = addr & -alignment

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

по-моему она возникает как раз не в cmd, а в консоли VS Code.

Александр Попов, не имею опыта использования VS Code, но предположу, что либо есть настройка кодировки для этой консоли, либо setlocale(LC_ALL, "") мог бы помочь именно здесь.

Как ни странно, именно en_US.utf8 с русским текстом на моей русской винде работает нормально...

Это как раз не странно. Для перекодировки только часть utf8 имеет значение, и, поскольку она обозначает кодировку, способную представить весь unicode, она будет работать для любых символов. Проблемы будут у людей использующих кодовые страницы типа сp1251.

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

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

Александр Попов, вопрос в том, зачем им быть wchar_t вместо того чтобы просто быть в текущей кодировке. Ведь ты их сам здесь же конвертируешь, причём считаешь, что текущая кодировка -- всегда en_US.utf8?

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

Александр Попов, этот вариант выглядит существенно лучше на мой взгляд. Но два момента у меня вызывают вопросы. Первый здесь: почему именно эта локаль, а не просто setlocale(LC_ALL, "")? Второй здесь: зачем там wchar_t, учитывая, что на выходе будут только символы из набора с64?

Почему появляется ошибка make: *** [Makefile:15: leak] Ошибка 1 при выполнении Makefile на C?

Maksim Ivanov, можно обернуть вызов valgrind в strace и потом сравнить логи успешного и сбойного выполнения на предмет отличия результатов выполнения системных вызовов.

Почему появляется ошибка make: *** [Makefile:15: leak] Ошибка 1 при выполнении Makefile на C?

значит все таки проблема в валгринде?

Maksim Ivanov, либо программа сама завершается со статусом 1 когда исполняется под valgrind.

Почему появляется ошибка make: *** [Makefile:15: leak] Ошибка 1 при выполнении Makefile на C?

Maksim Ivanov, можно ещё проверить код завершения процесса

valgrind --tool=memcheck --leak-check=yes ./$(NAME)

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

valgrind --tool=memcheck --leak-check=yes ./$(NAME) || echo "valgrind error code: $$?"

Округление при подсчёте в С++?

куда тут вставить округление

Miroslav Bodrich, не нужно тут вставлять округление никуда. Если есть цикл который должен сделать n шагов, то его счётчик должен быть целочисленным, а X нужно считать внутри цикла как функцию от целевого интервала и номера шага.

Почему появляется ошибка make: *** [Makefile:15: leak] Ошибка 1 при выполнении Makefile на C?

Поэтому и прошу помощи
> для полноты картины стоит показывать полный лог выполнения команды make
>> не вижу смысла в этом

Maksim Ivanov, ты видишь, что в этой последовательности что-то не так?

Почему появляется ошибка make: *** [Makefile:15: leak] Ошибка 1 при выполнении Makefile на C?

Полный лог высылать нет смысла, там нет никакой информации

Maksim Ivanov, ты зря упираешься, но дело, конечно, твоё.

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

да нет, дело не в шифровании:

int main(int argc, wchar_t* argv[])
...
printf("%s ", argv[i]);

Александр Попов, ещё раз, это не то, как выглядит функция main в стандартном C, а %s -- это не тот формат, который можно использовать для вывода строки wchar_t*. Этот код частично работает потому что ты не работаешь с отдельными символами argv, если бы ты стал это делать, ты бы сразу увидел, что что-то сильно не так. Попробуй в этой программе посимвольно напечатать аргументы.

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

читал в одном источнике, что на Windows новых версий наоборот аргументы в cmd.exe передаются в Unicode

Александр Попов, "передаются в Unicode" -- это недостаточно конкретно, потому что Unicode -- это грубо говоря идея перенумеровать все возможные символы. Поскольку символов много, у этой идеи есть несколько физических представлений, которые разбиваются на три больших класса. Один -- использовать 16- или 32-битовые коды фиксированной ширины для номера каждого символа (wchar_t). Другой -- представлять номер символа байтовым кодом переменной длины (UTF). Третий -- выбрать "интересное" подмножество символов и закодировать их Unicode-номера одним байтом (кодовые страницы). В *nix давно практикуется второй вариант (UTF), за тем что происходит в windows я не слежу, но подозреваю, что и они в конце концов прийдут к тому же.

я реализовал чтение аргументов через функции WinAPI, заключив их в #ifdef. Насколько это индусский код, и что с ним будет на Linux?

Что наифдефил -- то и будет.

в чём отличие преобразования (wchar_t*) в (char*) явным образом и вызова wcstombs?

В том, что в одном случае нет никакой перекодировки и ты оперируешь напрямую с байтами составляющими wchar_t, а в другом функция выполняет кодирование wchar_t в массив байт согласно настройкам локали (LC_CTYPE).

после расшифровки строки с русскими буквами и её вывода на консоль получался мусор. Это так и должно быть, или где-то в моём коде есть баг, который к этому приводит?

Ты можешь начать с простого варианта: используй "шифрование", которое ничего не меняет, и проверь, в шифровании ли дело, или в чём-то ещё.

Вопрос в том, что может я где-то усложнил себе жизнь?

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

Скомпилированный в GCC exe файл вылетает досрочно?

каким образом оно тогда не падало при отладке?

UB он такой.

Скомпилированный в GCC exe файл вылетает досрочно?

Я в интернете нашёл это решение. Чем-то адекватным его можно заменить, или нужно писать свою реализацию?

Я заменил его на это:

static char *itoa(int v, char *str, int base)
{           
        sprintf(str, "%d", v);
        return str;
}

Скомпилированный в GCC exe файл вылетает досрочно?

Я говорил о том, что после прохода отладчиком в папке остаётся exe файл.

Александр Попов, ты предлагаешь отлаживать файл который остаётся у тебя в папке, или ты выложил исходники для того, чтобы желающие могли собрать его сами? Я надеюсь, что второе, но см. выше, сборка просто так не работает.

Например так. Да, ламерский подход

Подход как подход. Но это не тот код, который ты выложил.

Скомпилированный в GCC exe файл вылетает досрочно?

Вот здесь ты выделяешь 33 байта для строки: https://github.com/popov654/alphacrypt2/blob/maste...
А вот здесь ты в тот же буфер добавляешь ещё один хеш: https://github.com/popov654/alphacrypt2/blob/maste...
strcat не меняет размер выделенной для строки памяти, это нужно делать самостоятельно перед её вызовом.