Здравствуйте, Nuzhny, Вы писали:

N>разделяют низкоуровневое ABI типа cdecl/stdcall и другой штуки.

Высота уровня здесь ни при чем. Буква "I" в аббревиатуре ABI обозначает факт стыковки программных сущностей, а "B" — тип этой стыковки. Чтобы эту стыковку можно было выделить сколько-нибудь явно, требуется спецификация. Правила оформления символических имен, обращения со стеком/регистрами и т.п., являются частью ABI. Если они различаются в отладочной и релизной сборках, то имеет смысл говорить о "несовместимости по ABI". Если же одна сторона ожидает найти по определенному адресу определенное значение, определенный результат вызова функции с определенными параметрами, но это явно не специфицировано в API, то имеет место "несовместимость сред" или что-то вроде этого, и говорить в этом контексте об ABI некорректно.

Здравствуйте, Nuzhny, Вы писали:

N>Очень наглядный пример — это debug и release сборки. Есть у тебя dll, которой ты передаешь, например, std::string или std:: vector. API не меняется, а ABI у debug будет другой...

Это не то, то — это различный формат самих данных, например:
есть у тебя USB-осциллограф, который может отдавать тебе массивы точек в формате {FILETIME time, float voltage}. Ты прочитал формат данных в документации, но обломался: x86 использует Little-Endian, а железка тебе отдаёт Big-Endian.
Потом ты разобрался в чём дело, и ещё раз обломался: ты на C# пишешь — поставил [StructLayout(LayoutKind.Sequential)] и успокоился, не учёл, что значения в структуре DSP-процессор выравнивает совсем не так, как это принято в винде.

Другой пример: решил ты, значит, попрактиковаться с графическими форматами — захотелось руками поковыряться в jpeg. И вот описал ты структурки, все нужные алгоритмы правильно написал — все тесты проходят, но нифига не работает. Угадай почему.

И ведь, сцуко, ни один чат-бот тебе не поможет с таким вопросом, не подскажет куда копать.

Здравствуйте, Философ, Вы писали:

Ф>И ведь, сцуко, ни один чат-бот тебе не поможет с таким вопросом, не подскажет куда копать.

Не согласен: парсинг данных и протоколов — это совсем другое.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, Nuzhny, Вы писали:

N>>Очень наглядный пример — это debug и release сборки. Есть у тебя dll, которой ты передаешь, например, std::string или std:: vector. API не меняется, а ABI у debug будет другой...

Ф>Это не то, то — это различный формат самих данных, например:
Зачем эти фантазии и философия? Вот есть же доки, они рулез.
Например https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html

Здравствуйте, ·, Вы писали:

·>Зачем эти фантазии и философия? Вот есть же доки, они рулез.
·>Например https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html

А смысл в доках от GCC, если бинарный интерфейс частенько даже не кодом записан? Псевдокодом, в pdf'ке.
Где GCC и где бинарный интерфейс какой-нибудь железяки?

by all of the tools that deal with binary representations of a program, including compilers, assemblers, linkers, and language runtime support.

Вот скажи, железяка предоставляет бинарный интерфейс? Может это делать? Тогда причём тут "binary representations of a program"?

Здравствуйте, Философ, Вы писали:

Ф>·>Зачем эти фантазии и философия? Вот есть же доки, они рулез.
Ф>·>Например https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html
Ф>А смысл в доках от GCC, если
Смысл в том, что там пишут фактическое название вещей, а не филосовствования.

Ф>бинарный интерфейс частенько даже не кодом записан? Псевдокодом, в pdf'ке.
Тогда это не ABI.

Ф>Где GCC и где бинарный интерфейс какой-нибудь железяки?
У железяк не ABI, а протоколы. По определению.

Ф>

Ф>by all of the tools that deal with binary representations of a program, including compilers, assemblers, linkers, and language runtime support.

Ф>Вот скажи, железяка предоставляет бинарный интерфейс?
Не предоставляет.

Ф>Может это делать?
Не может.

Ф> Тогда причём тут "binary representations of a program"?
Такое определение термина ABI.