res2001

Как я понимаю через выше aligment тем лучше?

Нет. Это бред. Тут не применимы термины лучше/хуже.

Alignment (выравнивание) - это просто свойство типа данных.
enum по умолчанию имеет тип int, соответственно и все его свойства наследуются. В С++ (с версии 17, если не ошибоаюсь) можно самому выбрать тип enum. Для выравнивания обычно действует простое правило - тип должен быть выровнен в памяти на границу кратную его размеру. Например у int размер 4 байта (обычно), и выравнивание должно быть по границе 4 байт. у char/uint8_t - размер 1 байт, соответственно ограничений по выравниванию нет, т.е. выравнивание по границе байта. Тип SDL_Color - это, видимо, структура, состоящая из 4 uint8_t (или что там в SDL используют для unsigned char), выравнивание для структуры берется из типа ее первого поля (если аттрибутами не задано другое).
Используй типизированный в uint8_t enum и будет тебе счастье.
https://en.cppreference.com/w/cpp/language/enum

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

В Си различают определение функции и предварительное объявление функции (он же прототип).
Точка с запятой ставится только в случае предварительного объявления функции.
Например:

int func(int a, inb);     // предварительное объявление
int func(int a, inb) { return a+b; }       // определение функции

В вашем примере main - это определение функции - точка с запятой не ставится.

В С++ используют вариант где не указывают расширение .h в include. С расширением это для исходников на Си.
Впрочем, как вы верно заметили, в плюсах это то же работает. Обычно внутри <cxxxx> просто делается #include <xxxx.h>

У вас в вопросе 2 варианта main.
В первом будет ошибка, во втором нет при сборке командой:
gcc main.c function1.c

Чтоб в первом случае не было ошибки нужно собирать командой:
gcc main.c
т.к. function1.c включается в main.c с помощью include и его не нужно повторно давать компилятору.
Эта команда для сборки второго варианта main не подойдет.

Ошибка выполнения stat для файла: No such file or directory

Потому что:
strcpy(filename, "mntEntry->mnt_dir");
Вы записываете в filename строку "mntEntry->mnt_dir", а не каталог.
Добавить затем слэш в конец можно так: strcat(filename, "/");
Или вручную:

size_t len = strlen(filename);
filename[len] = '/';
filename[len + 1] = '\0';

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

Есть еще момент. В линукс есть константа PATH_MAX она задает максимальный размер пути к файлу. Рекомендую ваши буфера для хранения путей делать размером PATH_MAX.

Утверждение пожалуй верно.

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

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

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

У издательства ДМК пресс есть книжки по ассемблеру (в т.ч. по АРМ) и по архитектуре компьютеров, можете посмотреть у них на сайте, там же можно и купить. Что плохо, они не делают скидку на электронные книги, как многие другие.
Изучать нужно ассемблер под ту платформу, на которой вы сможете писать тестовые программы. Обычно это х86, но при наличии, например, малинки или апельсинки можно и АРМ попробовать.
Конечно можно и эмулятором воспользоваться, но это лишние проблемы. А может и не лишние - если уж вы хотите ассемблер, то это может пригодиться.

Интересный вопрос. Ответа у меня нет, что-то не приходилось использовать режимы "+".
Попробуйте обнулять errno перед вызовом fopen. Возможно значение, осталось от предыдущего вызова. Вообще читать errno надо, только если fopen вернул NULL. При нормальном завершении errno не меняется.
И если pFile == NULL, очевидно, что не надо вызывать fclose.