Василий Дёмин

Максимум:

( a + b + sqrt(  ( a - b ) * ( a - b ) ) ) 
___________________________________________
                     2

Чтобы получить минимум, надо перевернуть знак перед корнем:

( a + b - sqrt(  ( a - b ) * ( a - b ) ) ) 
___________________________________________
                     2

Где SQRT - взятие корня квадратного

Код на плюсиках:

int32_t TheMadMax( const int32_t a, const int32_t b ) 
{
    const int32_t alpha = ( a - b );
    const int32_t beta  = alpha >> 31;
    const int32_t gamma = ( alpha ^ beta ) - beta;
    return ( a + b + gamma ) >> 1;
}

Референс

В любом нормальном курсе теории алгоритмов (или в соответствующей книге) с первых страниц объясняется, что нотация O() НЕ показывает зависимость времени выполнения алгоритма от количества элементов, поскольку не в состоянии учесть кучу факторов - от языка реализации до стиля написания кода программистом и даже архитектуры hardware вашего компьютера. Все что эта нотация показывает по сути - это как зависит время выполнения алгоритма от роста количества элементов в наборе - линейно, квадратично, логарифмично и пр. И этого в общем-то достаточно, что-бы уметь сравнивать алгоритмы между собой - для чего эта метрика и вводится.

Константа вылезает из деталей реализации операций. Вот сортировка пузырьком делает ровно n(n-1)/2 сравнения и помен в худшем случае. Еще столько же операций инкремента счетчика индекса, столько же проверок на конец цикла. Плюс еще n операций для внешнего цикла. И все это O(n^2). Хотя там есть есть /2 и операций четыре типа. И они еще разное время занимают. Скажем, проверки занимают 10 тактов, а инкрименты - 1. Но вся эта мишура не влияет на скорость роста и прячется в константе. Если все сложить. То будет C*n^2 +C2*n+C3 тактов на алгоритм.

MASM и FASM - это компиляторы, а не языки. Различия в коде для MASM и FASM только на уровне директив и макросов. У языка Ассемблера есть два основных диалекта - синтаксис Intel и синтаксис AT&T, а также различный набор инструкций для различных архитектур процессоров. Я рекомендую начать с эмулятора 8086 в реальном режиме и только освоив в должной мере основы, выбирать компилятор.

почему программа завершилась? Вмешалась ОС? Но если так, то почему?

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

Почему я не могу поменять значение самого указателя (ведь указатель - это всего лишь ссылка на адрес памяти, а не на значение).

Значение указателя ты поменять можешь, но это не то, что было написано в коде. В коде было написано поменять значение на которое указатель указывает. Поменять указатель было бы a = (int *)10;

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

Можешь, но под ОС с виртуальной памятью это в большинстве случаев не имеет смысла. API в таких ОС обычно устроены так, что ты просишь выделить область памяти с заданными характеристиками, а ОС выполняет выделение и возвращает тебе адрес выделенного участка.

получаю ошибку, ведь вряд ли адрес памяти у указателя хранится в виде 16-ричного целочисленного литерала.

В памяти всё хранится как последовательность байтов. Любую последовательность байтов можно проинтерпретировать как указатель. Но чтобы компилятор С понял что ты имеешь в виду, ему надо явно сказать, что ты хочешь проинтерпретировать целое число как адрес: int *a = (int *)0x0061FF18;

Почему так происходит?

Потому что стандарт С11 (9899:201x 6.7.4:7, черновик доступен тут) говорит следующее про спецификатор inline:

Any function with internal linkage can be an inline function. For a function
with external linkage, the following restrictions apply: If a function is declared
with an inline function specifier, then it shall also be defined in the same translation
unit. If all of the file scope declarations for a function in a translation unit include
the inline function specifier without extern, then the definition in that translation
unit is an inline definition. An inline definition does not provide an external
definition for the function, and does not forbid an external definition in another
translation unit. An inline definition provides an alternative to an external
definition, which a translator may use to implement any call to the function
in the same translation unit. It is unspecified whether a call to the function uses
the inline definition or the external definition.

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

inline void some_inline_func(uint32_t num)
{
    . . .
}

ты тем самым реализовал инлайн-версию этой функции, но не реализовал версию со внешней линковкой. А транслятор выбрал (вернее ты ему подсказал выбрать, опцией -O0) использовать реализацию функции со внешней линковкой, поэтому ты получил ошибку от линковщика.

Вариантов решения этой проблемы примерно 3:
- определить функцию следующим образом:

extern inline void some_inline_func(uint32_t num)
{
    . . .
}

Такая функция будет доступна из других единиц трансляции.

- либо определить функцию следующим образом:

static inline void some_inline_func(uint32_t num)
{
    . . .
}

Такая функция будет доступна только для данной единицы трансляции.

- оставить в этом исходнике всё как есть, а в каком-нибудь другом определить следующую функцию:

void some_inline_func(uint32_t num)
{
    . . .
}

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

Вообще-то это C/C++.

char url[макс_длина];
sprintf(url, "https://site.com/%s", <тут переменная>);
curl_easy_setopt(curl, CURLOPT_URL, url);

Открывайте файл в бинарном режиме "wb" и пишите туда через fwrite (лучше побайтово, чтобы не мучиться с переносимостью из-за порядком байтов в int).

Читайте, соответственно, через fread.

Для шифрования лучше всего, во-первых, байты в разном порядке писать, (не 0,1,2,3, а, скажем, 2,0,3,1) и, во-вторых, xor-ить их с какими-то константами. А еще лучше не с константами, а со случайными данными, которые тоже записываются в файл рядом. Или не рядом, так будет закономерность меньше видна.

Но все это может спасти только от людей незнакомых с reverse engineering'ом и отладкой. Более менее осведомленный ползователь посмотрит в ассемблерный код и поймет, что и как там читается и где и что надо поменять. Но да, это посложнее просто редактирования txt файла.

Ну и, artmoney с cheat engine никто не отменял.