Как найти полусумму 32-битных знаковых чисел?

Читайте ей по 4 байта 2 раза в char buf[4].
...
(int)buf[3] << 24 | (int)buf[2] << 16 поставит на место 2 старших байта

Не, не поставит. Вернее, не всегда. Примерно в половине случаев. А в другой половине случаев в верхних 8 битах окажутся единицы, а вся операция будет UB.

Тип 64-х битных чисел - long long. Вам в условии посоветовали им пользоваться.

int64_t же. Но если собирать числа сдвигами, то правильное 64-битное значение со знаком указанным выше способом не получится.

Сложить 2 числа сами сможете?

Нужно вычислить полусумму этих чисел, округляя полученный результат вниз.

А тут ещё в операции деления будет загвоздка. Потому что стандартный оператор деления округляет к 0 а не вниз.

Парсинг строки не через strtok на СИ. В чем заключается ошибка?

res2001, санитайзер -- инструмент, он несовершенен, но его можно улучшать (что вы и сделали). Но как инструмент он куда мощнее valgrind'а, потому что ему доступна вся информация из исходного кода. Например на следующий код valgrind ведь даже не почешется, в отличие от asan:

#include <string.h>

int i;
int j;

int main()
{
        void *pi = &i;
        char buf[8];
        void *pj = &j;

        memset(buf, 0, 16);
}

Парсинг строки не через strtok на СИ. В чем заключается ошибка?

Почему не работает, если в else дописать free(buf)?

Потому что у тебя по-прежнему переполнение буфера в этих местах (ты выделяешь strlen(buf), а надо на 1 байт больше):

parsed_string[(*size) - 1] = (char *)malloc(strlen(buf));
            strcpy(parsed_string[(*size) - 1], buf);

И чтобы два раза не вставать: опция компилятора gcc -fsanitize=address и программа valgrind могут тебе без нашей помощи говорить, где ты вылез за границы буферов.

Например, для твоей оригинальной программы:

$ gcc -fsanitize=address -g mem.c -o mem
$ ./mem mem.txt 
=================================================================
==14939==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000074 at pc 0x7eff8b502550 bp 0x7ffc978328c0 sp 0x7ffc97832070
READ of size 5 at 0x602000000074 thread T0
    #0 0x7eff8b50254f in __interceptor_strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301
    #1 0x55cda292992b in parse_string /home/jcmvbkbc/tmp/toster/mem.c:84
    #2 0x55cda2929492 in variable_processing /home/jcmvbkbc/tmp/toster/mem.c:55
    #3 0x55cda2929377 in main /home/jcmvbkbc/tmp/toster/mem.c:31
    #4 0x7eff8b2bd09a in __libc_start_main ../csu/libc-start.c:308
    #5 0x55cda2929219 in _start (/home/jcmvbkbc/tmp/toster/mem+0x1219)

0x602000000074 is located 0 bytes to the right of 4-byte region [0x602000000070,0x602000000074)
allocated by thread T0 here:
    #0 0x7eff8b543720 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:105
    #1 0x55cda29296de in parse_string /home/jcmvbkbc/tmp/toster/mem.c:79
    #2 0x55cda2929492 in variable_processing /home/jcmvbkbc/tmp/toster/mem.c:55
    #3 0x55cda2929377 in main /home/jcmvbkbc/tmp/toster/mem.c:31
    #4 0x7eff8b2bd09a in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301 in __interceptor_strlen
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa fd fa fa fa fd fa fa fa fd fa fa fa[04]fa
  0x0c047fff8010: fa fa 00 fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==14939==ABORTING

Вот это:

READ of size 5 at 0x602000000074 thread T0
    #0 0x7eff8b50254f in __interceptor_strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301
    #1 0x55cda292992b in parse_string /home/jcmvbkbc/tmp/toster/mem.c:84

как раз указывает на вызов strlen с буфером без 0-терминатора.

C++ или Си, на каком языке программы выполняются быстрее?

код на ассемблере выполнится быстрее чем на python

Kaktys_DH, а вот бесконечный цикл на ассемблере выполнится быстрее чем на питоне, например?

Какие дистрибутивы линукса позволяют при установке выбрать шифрование всего HDD?

...от жены там, соседа, ремонтной мастерской...
Но зачем /bin например шифровать?

Чтобы жена, сосед и ремонтная мастерская не подменили софт который спрашивает пароль от /home на софт, который этот пароль куда-нибудь, например, сохраняет.

Ошибка при компиляции проекта с использованием boost?

-std=c++11?

Как разделить файл по переносам?

Я уже поменял если что.

Trimsky, актуальный код покажи. Весь.

Как разделить файл по переносам?

Ничего, что у тебя сверху separator, а в цикле -- delim?

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

Как найти неправильную работу с памятью?

gcc -o -g progr *.o -lm

я не знаю вообще что делает, собирает программу с именем "-g", наверно (-o -g)?
Нет нужды в твоём случае отдельной командой линковать, можно компилировать и линковать одной командой gcc -g *.c -o progr -lm

Как найти неправильную работу с памятью?

Georgy123, смотри внимательно. Вот я накидал программку для теста, вот что показывает без -g:

==11828== Invalid read of size 1
==11828==    at 0x109153: main (in /home/jcmvbkbc/tmp/toster/a.out)
==11828==  Address 0x4a4204a is 0 bytes after a block of size 10 alloc'd
==11828==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==11828==    by 0x109146: main (in /home/jcmvbkbc/tmp/toster/a.out)

а вот что с -g:

==11846== Invalid read of size 1
==11846==    at 0x109153: main (vg.c:6)
==11846==  Address 0x4a4204a is 0 bytes after a block of size 10 alloc'd
==11846==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==11846==    by 0x109146: main (vg.c:4)

видишь разницу?

Появляется ошибка AccessViolationException: «Попытка чтения или записи в защищенную память». В чем может быть проблема?

A=%5i\nB=%5i\nC=%5i\nD=5i\nE=%f\n=%f\nH=\''%s\''",A,B,C,D,E,F,G,H

В строке формата A, B, C, D -- целочисленные, E и нечто без имени -- плавающие и H -- строка. А в аргументах есть ещё G. Это тоже надо исправить.

Появляется ошибка AccessViolationException: «Попытка чтения или записи в защищенную память». В чем может быть проблема?

guzya007, добавь сюда фикс D=5i

Как поместить параметр в стек?

массив нужно передать, а в ассемблере их нет

Olegofr3n77, в ассемблере есть адреса, а массив -- это непрерывный участок памяти начинающийся с заданного адреса.

Убрать указание размера функции?

Где можно найти размеры типов данных?

armadillo-cld, проще всего -- в заголовочных файлах где они определены.
Прямее всего -- написав программу которая будет печатать sizeof нужных типов.
Но зачем, если можно сдампить список экспортированнх функций из нужных библиотек, прогнать их через sed скрипт типа того: 's/\([^@]*\)/#define \1 \1/' и подключить получившийся файл?

Как удалить строку из матрицы?

приведи весь код, чтобы мы не гадали, где у тебя "Выводит" и что такое B

Убрать указание размера функции?

Не хочу Си. Хочу низкоуровневое программирование.

armadillo-cld, тогда непонятно, чего ты ноешь посчитать размеры списков параметров -- это твоё низкоуровневое программирование и есть, в чистом виде.

А, я вспомнил,

сложновато звучит

Ну ок, да, низкоуровневое программирование сложновато.

Убрать указание размера функции?

--kill-at

If given, the stdcall suffixes (@nn) will be stripped from symbols
before they are exported.

-- это противоположное тому, что нужно автору.

Убрать указание размера функции?

armadillo-cld, так пиши на С, он именно для упрощения этой ненужной сложности и был сделан.

Убрать указание размера функции?

Как мне узнать размер аргументов?

armadillo-cld, посмотреть на их типы, расширить типы уже 4 байт до 4, всё сложить.

Убрать указание размера функции?

как их можно по-быстрому считать?

armadillo-cld, компилятор С умеет их считать. Это одно из отличий C от ассемблера.