15432

для 32-битных что-то типа такого. надо считать байты и развернуть их (вы же на x86 программу делаете? он little endian).

unsigned int ReadBig32(FILE * in_file)
{
    unsigned char temp[4];
    fread(temp, 1, 4, in_file);
    unsigned int result = temp[3] | (temp[2] << 8) | (temp[1] << 16) | (temp[0] << 24);
    return result;
}

Установить 15 бит в 1:
var |= (1 << 14);
Установить 15 бит в 0:
var &= ~(1ul << 14);

Установить как вы просили:
var= 0x000100100fe80010ul | 0xfffffffff00ffffful;

Конкретно в вашем примере происходит вот что:
1) переменной "а" присваивается значение 1736704
2) переменная "а" переводится в float, получается значение 1736704.0
3) производится деление чисел с плавающей точкой- 1736704.0 на 65536.0
4) результат деления (26.5) записывается в переменную "b"

Настоящее преобразование чисел, о котором вы и спрашиваете, происходит только на шаге 2. В архитектуре x86 оно происходит с использованием специальных ассемблерных команд и floating-point сопроцессора. То есть быстро и автоматически. В более простых архитектурах это может быть реализовано программно (всего лишь вычислить экспоненту и мантиссу)
https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D...

Процессор это тупая железяка из транзисторов. Ну ладно, не настолько тупая, в современных x86 процессорах машинные коды на лету транслируются в еще более низкий уровень встроенным микрокодом. Но все все равно предположим, что это тупая железяка типа Intel 8086. Как происходит выполнение программы - процессор считывает очередной байт кода и смотрит, что же он такое считал. По значению байта, он определяет, что это за команда (сложение, вычитание) и сколько ещё нужно считать байт конкретно этого машинного слова (а они в x86 могут быть разной длины). Все это происходит на уровне железа, то есть нечто вроде "пятый бит 0, третий бит 1, ага! Это команда сложения двух восьмибитных регистров, надо переключить линию данных на арифметико-логическое устройство и считать туда еще два байта на шину данных. То есть операции очень и очень простые, на уровне бит, сигналов и чтения данных, никакого анализа кода и уж тем более никаких имен переменных. Вы же предлагаете на аппаратном уровне парсить сишный код, в котором при последовательном чтении иногда невозможно определить, что делать в данный момент!! А процессор в это время будет простаивать и считывать из памяти кучу ненужного текста.
Я вообще не представляю, как на уровне железа и транзисторов можно сделать синтаксический и лексический анализ сишного файла. Разве что сделать настоящий электронный мозг с миллиардом нейронов. Это уж точно не будет быстро, это вообще работать не будет. Изучите устройство компьютера, как именно работает процессор, научитесь думать на языке ассемблера, и поймёте всю абсурдность вашего предложения.

Так создавайте указатель сразу с местом, куда записывать, компилятор такое умеет - массив называется.
int pvar[1];
Почти тот же самый указатель, только теперь на стеке было дополнительно выделено место, и он в него указывает. Только изменять место, куда указывает, нельзя.

На Си легко "выстрелить себе в ногу" и упустить утечки памяти, переполнение буфера, гонки данных в параллельных потоках. Убедился в этом при создании похожего проекта.

Почитать - если стремитесь к максимальному быстродействию, разберитесь как работать с epoll и неблокирующими сокетами. Для работы по HTTP почитайте спецификацию и какие поля могут быть, как их парсить и обрабатывать, и т.д. Для парсинга пригодятся state-машины (это уже "основы конструирования компиляторов", по теме есть много вузовских учебников). Работа с сокетами напрямую подразумевает некий кастомный протокол - нужно придумать соглашения по формату передаваемых данных (заголовок, пакеты, и т.д.)

В случае 24 бит, на каждый пиксель приходится по 3 байта - значения для красного, зелёного и синего цветов.
Для 16 бит на пиксель приходится уже 2 байта, придётся "выдёргивать" цвета уже побитно (на красный и синий отводится 5 бит данных, на зелёный 6 бит)
8 бит - один байт на пиксель, либо оттенки серого, либо в заголовке будет таблица соответствий цветов, в которой каждому значению байта соответствует 24-битное значение цвета. Всё это придётся расшифровывать.
2 и 4 бита аналогично 8 бит, только ещё меньше цветов.
Помимо всего этого, может присутствовать RLE сжатие, которое придётся распаковывать и запаковывать. Сжатие примитивное, но всё же экономит место.

P.S. Если вы используете BMP библиотеку, которая любой формат вам превращает в набор значений RGB, заморачиваться и не нужно, либа сделает всё за вас.

В Windows драйвера находятся в ядре. Новый поток не создается, драйвер лишь обрабатывает поступающие запросы на чтение и перебрасывает их другим драйверам, например, usb mass storage или ahci. Которые, в свою очередь, взаимодействуют с хост-контроллерами USB или ATA.
Сам вызов ReadFile блокирует выполнение программы до завершения операции (но можно и асинхронно)

char * buffer = NULL;
char ** bufptr = &buffer;
some_alloc_function(bufptr);
If (buffer != NULL)
printf("alloc success\n");

эта программа пережимает только измененные блоки.
вряд ли оставляет полностью прежнюю таблцицу, но мало ли..
www.betterjpeg.com

Переполнение происходит, scanf читает всю строку до символа перевода строки, но буфер всего 4 байта, и происходит перезапись данных, что за буфером. Видимо дальше хранится имя файла, которое и выводится. Необходимо использовать безопасный scanf (в винде это scanf_s, в линуксе не знаю).