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

uint32_t' {aka 'long unsigned int'}

Сергей Соловьев, long unsigned int не может быть 32 бита на 64-битной машине, только в модели LLP64.

я специально посмотрел в исходники и…
typedef unsigned int __uint32_t;

чот как-то невнимательно посмотрел?

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

conversion from 'uint32_t' {aka 'long unsigned int'}
протестировал это … на x86_64

автор собирает 32-битный код, судя по всему

Является ли мой алгоритм криптостойким? Если нет, то где его уязвимость?

Таким образом мы только можем получить ксор всех этапов. Т.е. первых х байт из всех 16 этапов. Это не даёт никаких преимуществ потому, что мы не можем знать полный хеш

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

я думаю что не стоит рассматривать ситуации, когда большая часть текста является раскрытой. Это просто не имеет смысла

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

Почему компилятор пишет, что типы не совпадают?

одно я понял точно: универ, где я учусь, параша: нас учили использовать в таких случаях fflish(stdin)

70-C9-4E-54-03-2F, по хорошему универ вообще не должен "учить" деталям такого уровня. Но, увы, ровно то же самое говорили и мне в студенчестве в моём универе, 25 лет назад.

и у всех как ни странно работало

Я помню у меня тоже работало, в Borland C для MS/DOS.

с какой операционной системы или что у вас за терминал

Уверен, что имеет значение только то, какая используется libc -- в моём случае это glibc 2.36, но для полноты картины: моя ОС -- Debian 12.

Почему компилятор пишет, что типы не совпадают?

так ваш вариант с пробелом после спецификатора формата в scanf не работает должным образом

70-C9-4E-54-03-2F, я знаю. И я написал вариант на замену который считаю более хорошим, вот здесь.

и да будет вам счастье с ожидаемым поведением, описанное стандартом и чем-угодно

Вы поймите, я же не просто так это написал. Я поделился практическим наблюдением, что fflush(stdin) не работает и показал, что этому есть обоснование в мануале (кстати, в стандарте C99 вообще написано, что fflush для потока ввода -- UB). Не нужно из-за этого чувствовать себя уязвлённым, так работает этот сайт: люди указывают вам на ваши ошибки, а вы им -- на их.

Почему компилятор пишет, что типы не совпадают?

70-C9-4E-54-03-2F, я вас поздравляю, вы наблюдаете поведение не описанное стандартом, такое бывает, важно не принимать исключение за правило и не рассчитывать, что так будет всегда.

Почему компилятор пишет, что типы не совпадают?

лучше, скорее всего, очистить буфер используя fflush(stdin), как я указал выше.

70-C9-4E-54-03-2F, man fflush говорит, что это не работает для терминального ввода. И это подтверждается практикой.

не совсем понятно зачем в scanf("%d ", &num) нужен пробел. scanf будет бесконечно ожидать ввода любого непробельного символа после ввода num.

Да, лучше было бы выкинуть оттуда пробел, а getchar() заменить на scanf("%*[^+-*:]%1[+-*:]", &op);

Почему Python не видит файлы в Linux как в Windows?

"файл лежит в одной папке со скриптом" и "смотреть в текущую директорию" -- это две разные вещи. Как именно ты запускаешь скрипт в linux?

Контринтуитивный синтаксис объявления нескольких переменных одного типа?

const char это declaration-specifiers

Герман, да

а * это declarator

да, относится к declarator или его часть, поскольку помимо * в declarator обязательно должно быть ещё имя.

Можете объяснить код на STM32?

Это теперь конечно немного обесценивает мою интерпретацию порта E в двоичном коде.

Carmic Nauka, да нет, вроде всё ок с интерпретацией: значение led_state действительно сдвинули и получили что написано в комментарии.

Можете объяснить код на STM32?

мы же сдвинули это число на 8 разрядов влево, чтобы работать с битами от 8 по 15

Carmic Nauka, мы сдвинули значение влево когда передавали его как аргумент в функцию HAL_GPIO_WritePin. led_state от этого не изменился. Если бы мы написали HAL_GPIO_WritePin(..., led_state + 1, ...), led_state не увеличился бы на 1, со сдвигом всё то же самое.

Можете объяснить код на STM32?

led_state = led_state >> 1 | led_state << 7; Сдвиг выполняется от изначального числа два раза, т.е. 00000001.00000000 и 1.10000000.00000000 и тд.

Откуда в этой записи 8 нулей справа от точки? led_state -- 8-битное число, его значение в момент когда эта строчка выполняется в первый раз -- 3.

Почему не запускается приложение на linux alpine?

Предположу, что не хватает динамических библиотек. Что показывает ldd ./seeker на сервере?

Как исправить "неопределённая ссылка на «http::server::server::run()"?

target_include_directories(test PRIVATE ${YOUR_DIRECTORY})

maksimwork1980, target_include_directories -- это каталоги которые будут добавлены для поиска файлов подключаемых директивой #include.

add_executable(main ${PROJECT_SRC})
file(GLOB PROJECT_SRC
"*.h"
"*.cpp"
)

Добавление *.h в список исходников -- идея не очень.

Как загружатся с 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.