jcmvbkbc

char *str = malloc(0);
Правильно ли я понимаю, что в str находится начало выделянно памяти на 0 байт

Вот что говорит стандарт (c99, 7.20.3:1) о выделении 0 байт через malloc:

If the size of the space requested is zero, the behavior is implementation-
defined: either a null pointer is returned, or the behavior is as if the size were some
nonzero value, except that the returned pointer shall not be used to access an object.

Поскольку твоё обращение к этой памяти не вызывает SEGFAULT, то да, malloc вернул не NULL. Сколько байт реально было выделено зависит от реализации.

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

Да. Использовать эту память согласно стандарту нельзя.

Получается, магическим образом, самопроизвольно, между включениями VulkanTexture.h и VulkanglTFModel.h был объявлен define.

А на самом деле где этот define определяется и как это место относится ко всем этим заголовочным файлам?

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

Нет, не может, но возможно ты не вполне понимаешь сам, в каком порядке ты написал их подключение. Так, например, Helpers/VulkanTexture.h и VulkanTexture.h -- это один и тот же файл, или разные? Если один и тот же, то из-за #pragma once в нём он не подключается в VulkanglTFModel.h, а если разные -- то подключается.

Понять, что фактичиски куда подключается можно выполнив вместо шага компиляции только препроцессирование (например, для gcc заменив в команде компиляции ключ -c на -E). В выводе препроцессора не видно дефайнов, но видно когда подключается тот или иной файл и видно весь исходный код не относящийся к препроцессору.

что тут неправильно?

для однозначного ответа на этот вопрос не хватает определения типа Student.
Но судя по тому как всё падает, в Student есть не-POD поля, выделяющие и освобождающие память, например std::string или что-то типа того. Загружать их из файла просто читая записанное ранее содержимое памяти нельзя, потому что загруженные указатели будут ссылаться на невыделенную память, такие типы данных нужно по-честному сериализовывать.

где найти информацию о внутреннем устройстве long long int и unsigned long long int?

В стандарте: eelis.net/c++draft/basic.fundamental

у меня появилось впечатление, что long long int склеен из двух long int и дает псевдо длину в 64 бита. Поправьте меня, если я не прав

Можно и так на это смотреть, но почему "псевдо"? Вполне реальные 64 бита, на машинах с 64-битными регистрами это вообще "родной" тип данных.

int sum;

Переменная используется без инициализации.
Замени int sum; на int sum = 0;

Если master который был в новой репе не нужен, то следующих команд должно быть достаточно:

git remote add new <url_new_repo>
git push new +master

Есть ли возможность из файла узнать его (файла) местоположение?

readlink -f "$0" для исполняемого скрипта или readlink -f "$BASH_SOURCE" для скрипта загружаемого через source.

что значит код

ubfx r0, r0, #1, #1 -- извлечь битовое поле шириной 1 бит (правая единица) начиная с бита №1 (левая единица) из регистра r0 (правый r0) и поместить результат в r0 (левый r0).
bx lr -- перейти по адресу в регистре lr, обычно это возврат из подпрограммы.
Семантика опкодов легко гуглится по названию опкода и названию архитектуры процессора.

какая между ними разница

ubfx r0, r0, #1, #1
ubfx r0, r0, #2, #1
теперь, когда ты знаешь, что это за опкод, ты можешь понять сам, что они извлекают битовое поле начиная с разных битовых позиций.

что я делаю не так

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

Вот, что я попытался сделать:

push word 0
  pop es
  mov bx, 0x11*2+0xF000
  mov word [es:bx], int10-$$

Расскажи немного словами, что ты имел в виду когда писал это?

Я пытался гуглить, всю ночь потратил, …
проблема в отсутствии информации

Вот это нашёл? https://ru.wikipedia.org/wiki/Таблица_векторов_пре...

Самое важное для тебя и полностью достаточное для реализации твоей задачи предложение из этой статьи:

В микропроцессорах Intel 8086/80186 таблица векторов прерываний расположена в первом килобайте памяти начиная с адреса 0000:0000 и содержит 256 векторов прерываний в формате сегмент:смещение.

boot:
  push word 0
  pop es
  mov bx, 0x11*4
  mov word [es:bx + 2], cs
  mov word [es:bx], int10

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

Прерывания не знают. Это работа ОС -- организовать информацию так, чтобы при получении прерывания разобраться, откуда оно, зачем, и что с ним делать.

Прерывание в коде int 21h и прочие Это какое?

Любое прерывание инициируемое инструкцией int -- программное. В отличие от прерывания, инициируемого уровнем или фронтом сигнала подключённого к контроллеру прерываний.

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

выполнение прерывания std::cin>>line; Может и сутки длиться.

Системного вызова. std::cin >>line в конце концов превращается в системный вызов read.

Вот как по пунктам для этой команды. (С условием что есть еще 1 поток жаждущий ЦП).

Можно запустить такую программу, узнать её PID, выполнить где-нибудь cat /proc/<PID>/stack и увидеть следующую картину:

[<0>] wait_woken+0x67/0x80
[<0>] n_tty_read+0x426/0x5a0
[<0>] tty_read+0x135/0x240
[<0>] new_sync_read+0x115/0x1a0
[<0>] vfs_read+0xf4/0x180
[<0>] ksys_read+0x5f/0xe0
[<0>] do_syscall_64+0x33/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Т.е. поток выполнил системный вызов (ksys_read), зашёл в VFS, добрался до функции чтения в драйвере терминала (tty_read) и перешёл в состояние ожидания в глубине этой функции (wait_woken). Когда драйвер терминала получит данные для программы, он разбудит её поток и системный вызов завершится. До тех пор этот поток будет не готов к выполнению и скедулер ОС просто не будет выделять ему время.

Мне кажется, что тебе было бы полезно прочитать вторую и третью книжки (Understanding the Linux Kernel и Linux Kernel Developmen) из моего списка.