>> Булева логіка має до цих проблем безпосереднє відношення. На ній все побудовано + костилі.

А ше у всьому завжди винні регістри, бо не дають такої надійності як хотілось би; винен стек, бо через він є хостом для переповнень з доповнюючими експлойтами; винні процесорні операції переходу, бо дозволяють робити перехід всередину іншої операції, etc. Страшно жити, коротше кажучи, у всьому взагалі винні комп*ютери.

>> Те, що ви описали, це костилі. Яка МВР (мова високого рівня) логічно обробляє переповнення змінної (прапорці процесора це не логічно)?

C#, до прикладу, обробляє. Без усіляких доступних прапорців, чесно. І навіть не сама мова, а BCL/CLR. Взагалі, мова не має відношення до такого, по великому рахунку, оскільки є лише інструментом для формального імперативного запису — і все. Переповнилось шось? Будь ласкавий, оброби, або не допусти такої поведінки на етапі реалізації алгоритму. Я вже про це казав вище. Не подобається стандартний підхід — можна спробувати знайти якусь лібу, а якшо і такої нема — можна написати свою. Мейнстрімові платформи далеко не глупі люди розробляють, і щонайменше надають відповідну базу. А те, як хтось використовує цю базу — особисті речі кожного. Хтось робить це краще, хтось — гірше.

>> Ексепшини не панацея, вони створюють ілюзію надійності, насправді криють в собі небезпечні ефекти, помилки в компіляторі й рантаймі, бо ускладнюють систему.

Небезпеку криє у собі криворукість і нерозуміння концепцій системи. Компілятори, дякувати Богу, дуже навіть надійний генерять код для ексепшенів, в рантаймі помилок в реалізації виняткових ситуацій ще не бачив також — і це тішить. Те, шо система розробки ускладнюється — дуже навіть добре, оскільки дозволяє підіймати рівень мови на вищий щабель. Вас не турбує, шо SQL взагалі розробили декларативним, і шо він дуже навіть складний в реалізації, як і вся його інфрасистема? І невже не є виправданим ускладнення системи написання машинного коду в написання коду на асемблері, шо дуже обурювало «олд-скульників», як це було на початку комп*ютерної ери? А створення FORTRAN, коли програмісти на асемблері рвали на собі волосся? Висновок тут лише один: якшо хочеться писати надійніше, треба розробити розумну концепцію, вдало її реалізувати та вміло застосовувати. Справді. нічого складного.

>> WinAPI — не логічно, забули перевірити — добре що вилетіло, в гіршому випадку отримаєте малозрозумілу поведінку а ще гірше коли отримаєте правдоподібний результат.

Погоджуюсь, шо не логічно. А тому виняткові ситуації — дуже навіть логічно. Ви забули сказати, шо нелогічним було взяти за основу в WinAPI мову C, яка по дефолту маніпулювала лише значеннями, поверненими функціями. Але альтернатив C не було. Майкрософтівська Singularity, реалізована передусім на Sing#, і шось мені підказує, шо код тої осі набагато надійніший.

>> Всі ці труднощі накладаються й так на не просту проблему — верифікація алгоритма…

Це мене наштовхнуло хіба на думку, шо окрім того до C# все ж було би варто додати checked exceptions, як це було здійснено у Java.

>> Тому, АРП має підтримувати роботу із невизначеним числом, пам'ять також. Інтерфейси теж. Це значно спростить використання ЕОМ в реальній практиці.

Цікаво, як би ви кодували невизначене число, і чим вам не подобається стандартизований NaN. ) Справді, дуже навіть цікаво. ) Мене, передусім, цікавлять минулі та сучасні апаратні рішення, бо ж ми говоримо про історію та про досвід боротьби з помилками.

>> size8bitunsignet a;
>> a = 255;
>> //куча коду
>> a = a + 1; // результат сміття з точки зору додавання, якщо ви використовуєте ефект переповнення числа для якихось своїх цілей то руки вам відірвати треба, для цього необхідно визначати іншу операцію.

Нічо це не сміття, а лише модуль результату. І для обчислення CRC32 я буду, звісно ж, використовувати 64-бітні регістри, шоби мені за це мені не відірвали руки? Колись без того обходились, вміли переносити переповнення при обрахунках на листочку в стовчик навіть діти в школі (а вони поняття не мали про булеву алгебру), і зараз обходяться, і кодери на асмі прекрасно використовують carry-прапорець (неважливо, чи то Z80, чи то 8086). І то лише для мов, які не використовують виняткові ситуації. ;) В мене наразі лише одна думка: всі надумані «проблеми» лежать хіба у площині C/C++.