CityCat4

Я нашол .so файл и мне нужно скомпилировать в .c

Чаво сделать-та? Эт типа "я нашел полкило фарша и мне надо получить обратно мясо, из которого он сделан"? Операция, обратная компиляции (а компиляция, чувак - это получение из исходного кода исполняемого модуля) - называется - внезапно - декомпиляцией. И она для .c файлов возможна в очень примитивной форме только в том случае, если в модуле "забыли" отладочную информацию. Во всех других случаях она попросту невозможна :D

Не бывает.

Только в тех редких случаях, когда в программе почему-то сохранилась отладочная информация, можно составить приблизительное представление о коде. Если же там было простяцкоеgcc test.c -o test (или даже gcc -O2 test.c -o test) - усе, только дизассемблер.

Если в программе предполагается гуй, то лучше всего будет использовать C++ - в C придется делать очень много черновой работы

Или это миф, что C быстрее, чем Python?

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

Жигули, КАМАЗ и Бентли - это все автомобили. Но они сделаны для разных вещей, и будут хороши в той вещи, для чего были сделаны и плохи в тех вещах, для чего их не предназначали

Вообще-то стандартная запись
#include <math.h>
Означает она инструкцию искать math.h в стандартных папках инклудов. А запись в кавычках означает "возьми из текущего каталога"

Обьем массива известен.
Берем память

float *fptr;
fptr = (float *) calloc(sizeof(float*), MAX);

И все :) Массив указателей на float есть :) Теперь перемещаемся по нему, заполняем (разумеется и под числа тоже место нужно), когда надо - перемещаемся и ищем. Обычная работа с массивом, только для счетчика нужно float* использовать - тогда при простом инкременте у тебя он будет автоматом прыгать на следующий элемент массива.

Где стырил код - там же и ищи. Это может быть все, что угодно.

В С нет такого типа. Двоично-десятичный тип данных (он же "тип данных с фиксированной точкой") существовал в PL/1 (и, надо сказать поел мне немало мозгов при отладке программ вследствие своей крайней особливости при хранении в памяти).

Хайп вокруг ЯП Rust и C?

Нет никакого хайпа. Кто писал на С - тот пишет и дальше. Кто хочет модно-стильно-молодежно - пишет на Rust

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

Это не баг. Это фича (C)
Это не недостаток языка. Это его достоинство. (Я сейчас конечно же про чистый С, а не про плюса). Языков с автоуправлением памятью - хоть #опой жуй. "Убивцев" С - тоже не меньше - появляются и исчезают, как пузыри, оставляя после себя неприятный запах...

и не являются ли ошибки с памятью ошибками программиста,

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

Броском кухонного ножа можно спасти жизнь человека. А можно ее забрать. Является ли возможность ножа убить насмерть ошибкой его разработчика? Нет, потому что нож предназначен для тех, кто умеет его применять. Не умеешь - используй столовый.

разве общее число ошибок не перераспределяется на другие недостатки программы или программиста

Нет конечно же, это же не тараканы :) их потравили в одной квартире - они "перераспределились" в другие

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

(И, если это не преднамеренный стеб - переименовать учетку - как-то смешно выглядят элементарные вопросы от юзера с ником LinuxGod :ROFL: )

Эту переменную сама система устанавливать будет

Будет. Если скажешь. $? - это код возврата последней выполненной команды. Код возврата устанавливается вызовом exit()

man exit в общем.

Через fscanf() ничего вписать нельзя - это функция чтения Она ничего никуда не пишет (за исключением данных в переменные)

Вопрос поставлен неверно.

Первое. Компиляторы нынче жутко умные и могут весьма вольно обращаться с кодом (что весьма бесит, когда делаешь отладку - непременно нужно -O0 ("о ноль"). Поэтому имеет смысл рассматривать только код, откомпилированный с этой опцией, если ее убрать, все будет нафиг по-другому.
Второе. Смотрим ассемблерный код, сгенерированный компилятором и считаем такты по командам.
Третье. И выкидываем свои расчеты в мусорку, потому что процы - они тоже умные, у них всякие оптимизации, конвейеры, предикативные блоки и прочее.

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