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

В конфигурационных файлах моих проектов на разных языках программирования есть как повторяющиеся, так и отличающиеся настройки.
Часто, бывает, нужно работать сразу с несколькими проектами.
В vs code, когда открываешь проект, настройки можно определить только для всего проекта в подпапке .vscode, для подпапок настройки переопределить нельзя.

У меня давно была идея вынести общие настройки для всех проектов на уровень решения, а остальные настройки оставить или переопределить на уровне отдельного проекта.
Сегодня я нашёл способ как частично реализовать мою идею с разделением настроек.
Не знаю в какой версии это добавили, но в vs code есть такая функция, как рабочая область (workspace), это похоже на solution из IDE visual studio.
В рабочей области можно собрать несколько проектов, которые даже могут лежать в разных местах, и определить общие настройки для всего решения и отдельные для каждого проекта.
Какие проекты будут включены и их названия, а так же общие settings, tasks и launch определяются в файле рабочей области *.code-workspace.

Жаль, на уровне папки можно не все настройки переопределить, а так же настройки внутри подпапок проекта всё равно не будут работать.
Но в таком случае можно подпапку проекта добавить в рабочую область, а в проекте её скрыть.
Звучит, как костыльное решение, но если есть такая необходимость, оно будет работать.

https://code.visualstudio.com/docs/editor/multi-root-workspaces

ссылка на канал | ссылка на группу

debugConsole: форматы и их вывод в консоли отладчика gdb.
vscodeWatch: форматы и их вывод в окне контрольные значения в редакторе кода vs code.

Сегодня я отлаживал windows SEH исключения, и мне нужно было в отладчике видеть код исключения в 16 системе счисления.

Помню, если в vs code после имени поставить запятую и число, он станет интерпретировать объект или адрес, как массив.
Немного поэкспериментировал и нашёл значения, которые действительно меняют представление числа во вкладке контрольные значения.

Немного поискал и почитал документацию.
Похоже, это всё благодаря поддержке от отладчика gdb.
Ещё заметил, что не все форматы из документации работают в vs code и наоборот в консоли отладчика.

Вывод в соответствии с типом данных в консоли gdb:
Синтаксис:
команда[/формат] объект

> -exec output code
code = 3221225477

Вывод в 2 системе счисления:
> -exec output/t code
code = 11000000000000000000000000000101

Вывод в 8 системе счисления:
> -exec output/o code
code = 030000000005

Вывод беззнакового в 10 системе счисления:
> -exec output/u 3221225477
code = 3221225477

Вывод знакового в 10 системе счисления:
> -exec output/d code
code = -1073741819

Вывод в 16 системе счисления:
> -exec output/x code
code = 0xc0000005

Вывод в виде адреса:
> -exec output/a code
code = 0xc0000005

Вывод в виде символа:
> -exec output/c code
code = 5 '\005'

Вывод в виде числа с плавающей точкой:
> -exec output/f code
code = -2.00000119

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Через отладчик gdb я смог изменить program counter (instruction pointer, rip) и сделать, что я хотел)).

Инструкция, где возникает исключение:
-exec set $pc = 0x7ff682701750

Проверка условия и сообщение об ошибке после неё:
-exec set $pc = 0x7ff682701757

Вот бы windows при EXCEPTION_CONTINUE_EXECUTION и некотором флаге мог сам продолжать выполнение со следующей инструкции.

Получилось именно так, как я и хотел:
1) возникает исключение
2) вызывается обработчик SEH исключения
3) в глобальную переменную сохраняется код исключения
4) исключения обрабатывается и выполнение программы продолжается
5) выполнение возвращается на инструкцию, где возникло исключение
6) я меняю rip на проверку условия
7) выводится ошибка STATUS_ACCESS_VIOLATION из моего кода на разыменование нулевого указателя
8) можно спокойно сохранять файлы журнала, делать другие действия и завершать программу

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

После моих манипуляций в конце программы почему-то возникают исключения (access violation и другие).

Я задумался, могу ли я изменением регистра rip пропускать часть важных подготовительных инструкций.
Поэтому теперь я знаю, что в vs code во время отладки можно открывать ассемблерный код).

ctrl + shift + p -> open disassembly view, либо через ПКМ по файлу исходного кода -> open disassembly view.

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Продолжаю экспериментировать и исследовать механизм Vectored Exception Handler (windows SEH).

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

Чтобы в VEH возобновить исполнение программы и пропустить текущую инструкцию, которая привела к возникновению исключения, надо записать в регистр instruction pointer (на x64 это Rip, на x32 Eip) адрес начала следующей инструкции, но нужно знать размер пропускаемой инструкции в байтах.
Видимо, для этого придётся написать дисассемблер длин инструкций или найти готовое решение.

Можно просто увеличивать instruction pointer на 1 до тех пор, пока он не начнёт указывать на начало следующей инструкции, но я считаю это плохим решением.
Такой подход почти всегда будет приводить к возникновению новых ненужных (побочных) исключений, некоторые из них: STATUS_ACCESS_VIOLATION, EXCEPTION_ILLEGAL_INSTRUCTION.

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Небольшое дополнение про контрольные значения в vs code.

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

Мне нужно было видеть текущий адрес в регистре Rip (instruction counter на x64) без постоянного отвлечения на консоль отладчика:
-exec output/x $pc

ссылка на канал | ссылка на группу

С версии 1.25 от июня 2018 года в vs code появился портативный (переносной) режим.
https://code.visualstudio.com/updates/v1_25#_portable-mode

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

Доступен этот режим для всех трёх распространённых операционных систем: windows, linux и macOS и только для редактора, загружаемого в виде архива (*.zip, *.tar.gz).

Инструкция, как включить портативный режим для vs code или vs codium:
https://code.visualstudio.com/docs/editor/portable
https://github.com/VSCodium/vscodium/blob/master/docs/index.md#portable

Если пересказывать инструкцию кратко, то в папке установки нужно создать папку data, и внутри неё ещё три папки user-data, extensions и tmp (для macOS будет немного по-другому).

Выше вы можете скачать архив с расширением zip или 7-zip, в котором есть уже готовая иерархия пустых папок, содержимое которого надо просто разархивировать в корневую папку редактора.

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

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

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

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Как же мне нравится, когда код простой и явный.
(Ну, хотя бы для меня и по моим меркам)

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

Функция из byteAlgorithm работает, а чтобы компилятор не оптимизировал её код в вызов функции memcpy из стандартной библиотеки языка, использовал следующие pragma директивы препроцессора для gcc (mingw):

#pragma GCC push_options
#pragma GCC optimize ("-fno-tree-loop-distribute-patterns")
void byteCopy(uint8_t* from, uint8_t* to, int64_t size, status_s* status)
{
    ...
}
#pragma GCC pop_options

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

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Как сломать отладку в vs code за 1 секунду?

Всего лишь попытаться вызвать функцию по её адресу в контрольных значениях)).
(unsigned long)(*0x7ffd10f15bf0)(void)()

С чего всё началось и как я вообще додумался так сделать?

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

В моём модуле динамической памяти я поймал странное поведение.
Функция GetProcessHeap завершалась успешно, но GetLastError возвращала код 126: ERROR_MOD_NOT_FOUND (The specified module could not be found).
Из-за этого модуль сообщал о неуспешной операции.

Решил проверить последний код ошибки в самом начале main и получил тот же самый код, что мне показалось странным.
И я захотел начать отладку ещё до начала main где-то в startfiles или crt mainCRTStartup.
А возвращаемое значение из функции GetLastError отслеживать в контрольных значениях, но что-то пошло не так...

ссылка на канал | ссылка на группу