Подобные ошибки создают уязвимости из числа наиболее часто встречающихся в таком широко используемом программном обеспечении, как Firefox, Chrome, Windows, Android и iOS. Я больше года отслеживал информацию о проблемах с безопасностью в этих проектах, и почти в каждом релизе этих продуктов больше половины уязвимостей связаны с некорректной работой с памятью.
Ещё больше беспокоит тот факт, что уязвимости высокого и критического уровней (дающие возможность атакующему выполнять на вашем компьютере произвольный код; это самые опасные уязвимости) -- почти всегда используют некорректный доступ к памяти. За последний год, изучая защищённость широко используемых библиотек для обработки изображений ImageMagick и GraphicsMagic, я обнаружил более 400 уязвимостей этой категории.
Квалифицированный мужик.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>И переписать на них все, что можно переписать.
Еще эффективнее было бы кроме этого переделать все железяки на гарвардскую архитектуру, и заменить их. И примерно так же реалистично.
Здравствуйте, Sharowarsheg,
S> Еще эффективнее было бы кроме этого переделать все железяки на гарвардскую архитектуру, и заменить их. И примерно так же реалистично.
Хмм. Железяки с гарвардом точно так же подвержены уязвимостям. Есличо, как практик говорю.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, Sharowarsheg,
S>> Еще эффективнее было бы кроме этого переделать все железяки на гарвардскую архитектуру, и заменить их. И примерно так же реалистично.
V_S>Хмм. Железяки с гарвардом точно так же подвержены уязвимостям. Есличо, как практик говорю.
Managed языки тоже подвержены уязвимостям, это если из имеющихся.
А вообще
надо бы создать более защищенные, чем С++, языки программирования. И переписать на них все, что можно переписать.
ну и, соответственно, надо бы создать более защищенные железяки (чем гарвардская архитектура), и заменить все железяки, которые можно заменить.
S>надо бы создать более защищенные, чем С++, языки программирования. И переписать на них все, что можно переписать.
S>ну и, соответственно, надо бы создать более защищенные железяки (чем гарвардская архитектура), и заменить все железяки, которые можно заменить.
Имеем "ассиметричность информации на рынке" — в полной красе!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
S>>А вообще S>>
S>>надо бы создать более защищенные, чем С++, языки программирования. И переписать на них все, что можно переписать.
S>>ну и, соответственно, надо бы создать более защищенные железяки (чем гарвардская архитектура), и заменить все железяки, которые можно заменить. LVV>Имеем "ассиметричность информации на рынке" — в полной красе!
Создал новый консольный проект на C++ в VC2017 (сегодня обновил её).
Начал его(проект) рихтовать, а потом откатил назад чтобы запостить сюда:
// test_for_oledb_property_v2.cpp : This file contains the 'main' function. Program execution begins and ends there.
//#include"pch.h"#include <iostream>
int main()
{
std::cout << "Hello World!\n";
}
// Run program: Ctrl + F5 or Debug > Start Without Debugging menu
// Debug program: F5 or Debug > Start Debugging menu
// Tips for Getting Started:
// 1. Use the Solution Explorer window to add/manage files
// 2. Use the Team Explorer window to connect to source control
// 3. Use the Output window to see build output and other messages
// 4. Use the Error List window to view errors
// 5. Go to Project > Add New Item to create new code files, or Project > Add Existing Item to add existing code files to the project
// 6. In the future, to open this project again, go to File > Open > Project and select the .sln file
А вы тут про "с памятью неправильно работают".
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, LaptevVV, Вы писали:
LVV>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования.
Смысл в рекламе rust.
LVV>И переписать на них все, что можно переписать.
Проблема как раз не в языках, а в этом "всё"-м. Люди вынуждены использовать и доверять внешним библиотекам, т.к. создавать самим их с нуля очень накладно.
Да в здравом уме это будет финансировать? Проще это "всё" положить в виртуальную машину и её контролировать.
тут утверждают что проблема интернетов не в c++, а в распи№%@$стве лёгком бардаке.
Здравствуйте, LaptevVV, Вы писали:
LVV>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>И переписать на них все, что можно переписать.
Позиция автора достаточно понятна, но она стремительно теряет актуальность. В основном картина, описанная там, характерна для второй половины 1990-х, начала 2000-х. Это тогда активно соревновались, кто больше найдёт дырок переполнения буфера, а названия типа imap-uw вызывали у всех, кто хоть немного слышал такое, фейспалм или вырывание волос на себе, в зависимости от характера или настроения.
Примерно тогда же начались затыкания наиболее мрачных видов дырок — в работе с C-like строками — которые привели к появлению подпорок в виде функций типа strlcpy, strncat_s, и тому подобных. Именно эта проблема в основном решена. Да, отдельные случаи вылазят и сейчас. Но их относительная доля, по сравнению с прежней картиной, ничтожна.
А вот другие виды уязвимостей вышли на передний план, например:
1. SQL injections. Против них никак не помогает, например, что PHP сам управляет памятью и не позволяет выйти за границы. Зато в официальной документации PHP до сих пор открыто присутствует формирование запроса через прямую подстановку, и то — вызов mysql_real_escape_string там появился достаточно недавно (а должен был ещё 20 лет назад);
3. Разнообразные возможности выйти из sandboxʼа полномочий в скриптах на веб-страницах и т.п;
4. Проблемы криптографии (типа доморощенного дырявого алгоритма);
и так далее и так далее, смотреть хотя бы CWE list —
никакая замена C++ на Rust/Go/etc. этому не поможет.
LVV>Алекс -- специалист по безопасности софта в проекте Mozilla, где он занимается песочницей и борется с уязвимостями в проекте Firefox. Ранее он был программистом в компании the United States Digital Service, а также членом совета директоров двух организаций: Python Software Foundation и Django Software Foundation.
Занятие формирует мировоззрение, а молотку всё вокруг кажется гвоздями.
Rust для Firefox, скорее всего, на пользу. Но не против уязвимостей, а против потери памяти при работе (что характерно для всех браузеров).
И даже проблемы того же sandboxingʼа он не исправит.
Здравствуйте, LaptevVV, Вы писали:
LVV>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>И переписать на них все, что можно переписать.
По-моему, это все мелочи. Реальная проблема заключается в том, что C++ — это ОЧЕНЬ сложный язык программирования. У человека в голове есть вполне конечное число извилин, и если 80% из них заняты борьбой с языком программирования, на все остальное остается только 20%.
Кстати, rust, за который агитирует автор статьи, не сильно проще C++. И я предполагаю, что программы на rust'е будут в среднем не более качественные. Хотя, наверное, там будут популярны не ошибки переполнения буфера (от которых rust защищает), а какие-то другие ошибки.
Здравствуйте, qwertyuiop, Вы писали:
Q>Можно вкратце, о чем там речь?
Речь там о том, что большая часть ошибок в программе связана с некорректным доступом к памяти (переполнение буфера, выход за границу массива, использование уже освобожденной памяти и т.п.), а C++ не предоставляет автоматической защиты от такого рода ошибок. И что есть более другие языки программирования, например, любимый мозиловцами Rust, которые такую защиту предоставляют. И если переписать все программы на таких языках, то орки превратятся в эльфов, и мир станет лучше, добрее и безопаснее.
Здравствуйте, Pzz, Вы писали:
Pzz>Кстати, rust, за который агитирует автор статьи, не сильно проще C++. И я предполагаю, что программы на rust'е будут в среднем не более качественные. Хотя, наверное, там будут популярны не ошибки переполнения буфера (от которых rust защищает), а какие-то другие ошибки.
Есть таки разница, что на Rust надо постараться, чтобы скомпилировалось. А на C++ это проще — именно в основных проблемных зонах — но потом сложнее найти, почему не работает
Остальные ошибки, о которых я упоминал в предыдущем комментарии, от этой замены не уйдут, и не появятся.
Здравствуйте, LaptevVV, Вы писали:
LVV>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>И переписать на них все, что можно переписать.
Ну, он прав абсолютно. Но, увы, этого никто делать не будет.
Не только из-за С++. Есть проблема гораздо посерьезней — TCP. Это вообще тренд в последнее время, хаять все технологии зарекомендовавшие себя на протяжении 30++ лет и доказавшие свою жизнеспособность и гибкость, менять их на кота в мешке, принимая безумное количество сырых стандартов и пытаясь выгадать себе конкурентное преимущество.
Да, и конечно, ни в коем случае никакой обратной совместимости!
веткой, мне кажется.
V> Это вообще тренд в последнее время, хаять все технологии зарекомендовавшие себя на протяжении 30++ лет и доказавшие свою жизнеспособность и гибкость,
TCP, конечно, не самая худшая разработка, но "гибкостью" он не обладает от слова "совсем".
Претензий к нему накопилось столько, что и без QUIC тянет на необходимость TCPv2.
V> менять их на кота в мешке, принимая безумное количество сырых стандартов и пытаясь выгадать себе конкурентное преимущество. V>Да, и конечно, ни в коем случае никакой обратной совместимости!
А какая тут совместимость может в принципе быть?
Трещит сова, не налазит. ((c) один местный завсегдатай)
Здравствуйте, LaptevVV, Вы писали:
LVV>За последний год, изучая защищённость широко используемых библиотек для обработки изображений ImageMagick и GraphicsMagic, я обнаружил более 400 уязвимостей этой категории. LVV>[/q] LVV>Квалифицированный мужик.
Скорее всего запустил C++ анализатор увидел количество ворнингов — вот и вписал цифру, учитывая его признание что програмировал на С++ последний раз в коледже.
Большинство этих проблем в С. На С++ с STL можно писать как на бейсике и не надо создавать 30 новых языков.
Здравствуйте, Pzz, Вы писали:
Pzz>Речь там о том, что большая часть ошибок в программе связана с некорректным доступом к памяти (переполнение буфера, выход за границу массива, использование уже освобожденной памяти и т.п.), а C++ не предоставляет автоматической защиты от такого рода ошибок. И что есть более другие языки программирования, например, любимый мозиловцами Rust, которые такую защиту предоставляют.
И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, qwertyuiop, Вы писали:
Q>И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
Защита заключается в том, что программа детерминированно сдохнет, вместо того, чтобы недетерменированно делать неизвестно что
Здравствуйте, qwertyuiop, Вы писали:
Q>И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
А на Ц++ программа не вылетит (сразу — но будет вылетать каждый нечетный четверг в новолуние), а выдаст юзеру цифру. Глупый юзер поверит этой цифре, примет на ее основе решение и спустит все свои деньги.
Здравствуйте, Pzz, Вы писали:
Pzz>По-моему, это все мелочи. Реальная проблема заключается в том, что C++ — это ОЧЕНЬ сложный язык программирования. У человека в голове есть вполне конечное число извилин, и если 80% из них заняты борьбой с языком программирования, на все остальное остается только 20%.
Не совсем так. С++ начиная со стандарта 11 года поворачивается к разработчику всё же лицом, а не известно каким местом. Освоив некоторые техники работы с контейнерами, смартпойнтерами и прочими вещами, можно уже не задумываться об этом постоянно. Что не отменяет высокие минимальные требования к мозгам и просто адскую кривую обучения в сравнении с языками попроще (Java, Python).
Здравствуйте, AlexRK, Вы писали:
LVV>>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>>И переписать на них все, что можно переписать. ARK>Ну, он прав абсолютно. Но, увы, этого никто делать не будет.
Ну создали Rust, который как бы может заменить C++. В итоге на Rust выходит ничуть не менее запутанная кодовая база, может даже более запутанная. И в чем тут выгода в переписывании с одного избыточно сложного инструмента на другой?
При этом, многим проектам хорошо бы помог сам факт переписывания. И не так важно, перепишут ли с C++98 на Rust, что потребует довольно серьезный финансовых вливаний, или на C++17, что окажется ощутимо дешевле и предсказуемее. Современный C++ в подавляющем количестве случаев и есть тот новый, безопасный язык с которым надо работать.
Здравствуйте, kaa.python, Вы писали:
KP>Ну создали Rust, который как бы может заменить C++. В итоге на Rust выходит ничуть не менее запутанная кодовая база, может даже более запутанная. И в чем тут выгода в переписывании с одного избыточно сложного инструмента на другой?
Экономической выгоды нет, сплошные убытки.
Для софта выгода может быть — в потенциально большей предсказуемости, хотя в количественном выражении посчитать ее я не берусь.
This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical.
KP>При этом, многим проектам хорошо бы помог сам факт переписывания. И не так важно, перепишут ли с C++98 на Rust, что потребует довольно серьезный финансовых вливаний, или на C++17, что окажется ощутимо дешевле и предсказуемее.
Безусловно. Поэтому я и говорю, что никто ничего переписывать не будет. Инерция.
KP>Современный C++ в подавляющем количестве случаев и есть тот новый, безопасный язык с которым надо работать.
Надо работать? Вероятно, в большинстве случаев да. Безопасный? Категорически нет.
Здравствуйте, qwertyuiop, Вы писали:
Pzz>>Речь там о том, что большая часть ошибок в программе связана с некорректным доступом к памяти (переполнение буфера, выход за границу массива, использование уже освобожденной памяти и т.п.), а C++ не предоставляет автоматической защиты от такого рода ошибок. И что есть более другие языки программирования, например, любимый мозиловцами Rust, которые такую защиту предоставляют.
Q>И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
Ты троллишь или серьёзно не понимаешь?
Если программа открыто вылетит, это лучше, чем если она незаметно для себя и для пользователя испортит данные или даст неверный ответ.
К тому же, открытый вылет оставляет хотя бы адрес сбоя (а при минимальных усилиях и traceback), по которому легче найти место ошибки, чем по невнятным "глючит, цифры путает".
Здравствуйте, kaa.python, Вы писали:
LVV>>>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>>>И переписать на них все, что можно переписать. ARK>>Ну, он прав абсолютно. Но, увы, этого никто делать не будет. KP>Ну создали Rust, который как бы может заменить C++. В итоге на Rust выходит ничуть не менее запутанная кодовая база, может даже более запутанная.
С чего вывод про запутанность?
KP> И в чем тут выгода в переписывании с одного избыточно сложного инструмента на другой?
Если инструмент ловит большинство ошибок на компиляции и помогает их ловить в рантайме, то он лучше именно этим.
KP>При этом, многим проектам хорошо бы помог сам факт переписывания. И не так важно, перепишут ли с C++98 на Rust, что потребует довольно серьезный финансовых вливаний, или на C++17, что окажется ощутимо дешевле и предсказуемее. Современный C++ в подавляющем количестве случаев и есть тот новый, безопасный язык с которым надо работать.
Только при условии жесточайшего контроля за _всей_ кодовой базой.
Достаточно одного места, где слишком вольно обращаются с указателями, чтобы всё посыпалось.
И анализ, чтобы отловить такие места, сильно сложнее, чем для Rust.
Здравствуйте, AlexRK, Вы писали:
ARK>Экономической выгоды нет, сплошные убытки. ARK>Для софта выгода может быть — в потенциально большей предсказуемости, хотя в количественном выражении посчитать ее я не берусь.
Современный C++ дает достаточно предсказуемости при использовании в связке с современными инструментами. В качестве примера можно взять GSL, clang-tidy, санитайзеры и конечно же тесты. Основное отличие C++ от Rust в данном случае будет в том, что инструменты в C++ отдельны от компилятора и это ведет к высоким рискам их игнорирования. К примеру у нас сейчас многокомпонентный проект на C++14 и Go. Так как C++ часть довольно плотно покрыта инструментами по контролю, нет ни дедлоков, ни ликов, ни двойного освобождения памятью ни каких других около-C++ страшилок. То есть качество вполне сопоставимо с качеством достижимым в Go.
ARK>Вот что излагает заинтересованная сторона (можно верить, можно нет): https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html ARK>
This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical.
Полагаю что в случае с предыдущими попытками они не делали кардинальной замены системы, а просто пытались подставить правильные костыли. Полная переработка той же командой что смогла осилить Rust (осилить который ничуть не проще чем C++) привела бы к такому же результату.
ARK>Надо работать? Вероятно, в большинстве случаев да. Безопасный? Категорически нет.
Безопасен при использовании современного инструментария. Разница лишь в том, встроен инструментарий или идет сбоку.
Здравствуйте, netch80, Вы писали:
N>С чего вывод про запутанность?
Много раз пытался на нем писать. Если заглянуть в образцово показательную библиотеку типа tokio, то просто волосы везде шевелятся от перспективы поддерживать такой код.
N>Если инструмент ловит большинство ошибок на компиляции и помогает их ловить в рантайме, то он лучше именно этим.
В современном C++ достаточно развитый инструментарий для обеспечения достаточной защиты от типичных страшилок. При этом от перечисленных тобой же проблем
ни C++ ни Rust не защищают
N>Только при условии жесточайшего контроля за _всей_ кодовой базой. N>Достаточно одного места, где слишком вольно обращаются с указателями, чтобы всё посыпалось. N>И анализ, чтобы отловить такие места, сильно сложнее, чем для Rust.
Это очень легко решается при помощи санитайзеров и тестов.
Здравствуйте, kaa.python, Вы писали:
KP>Современный C++ дает достаточно предсказуемости при использовании в связке с современными инструментами. В качестве примера можно взять GSL, clang-tidy, санитайзеры и конечно же тесты. Основное отличие C++ от Rust в данном случае будет в том, что инструменты в C++ отдельны от компилятора и это ведет к высоким рискам их игнорирования. К примеру у нас сейчас многокомпонентный проект на C++14 и Go. Так как C++ часть довольно плотно покрыта инструментами по контролю, нет ни дедлоков, ни ликов, ни двойного освобождения памятью ни каких других около-C++ страшилок. То есть качество вполне сопоставимо с качеством достижимым в Go.
Согласен. Разница как раз в "насильственном насаждении" безопасности растом — в долгосрочной перспективе это хорошо. Можно провести аналогию (лживую, как и другие аналогии) со статической и динамической проверкой типов — хорошее тестовое покрытие динамически типизированного кода вполне ставит его на уровень статического по безопасности. Но когда конпелятор следит — оно всё же надёжнее как-то.
Ну и вообще С++ уже чрезмерно, безобразно огромен и сложен. И новый мусор всё прибывает и прибывает. "requires requires", "noexcept(noexcept)", "export import", метаклассы, и так далее. Рано или поздно вся эта гора коллапсирует под собственным весом в чорную дыру (глубокое легаси).
Здравствуйте, kaa.python, Вы писали:
KP>Много раз пытался на нем писать. Если заглянуть в образцово показательную библиотеку типа tokio, то просто волосы везде шевелятся от перспективы поддерживать такой код.
Я не писал на расте, но вроде бы в этом коде чего-то сильно непонятного нет. Вполне разборчиво и однородно. Думаю, что можно на расте наговнокодить куда сильнее.
Про QUIC, это я просто так, к иллюстрации современных трендов, а вообще то конечно о С++ и Rust.
Ну просто уже все было: IP/Sec, IP6, SPDY и т.д. лет уже 20 говорят что все не работает, нужно менять, а воз и ныне там. Просто это все о дальновидности всех этих решений. Сначала всех силком садят на HTTPS, кого надо и кого не надо, а потом говорят что мол, у нас Hand-Shake лишний и тормозит и вот новый стандарт все решит... Ладно, поживем увидим
По поводу Rust. Основная идея мне нравится:
— константные ссылки
— семантика перемещения по умолчанию
— автоматический подсчет ссылок
— все статически проверяется компилятором
Но остается главный вопрос, что делать с тоннами кода который есть на С++ и еще будут написаны, если нет никакого интеропа между?
С++ потихоньку заменяет и дополняет С, т.к. между ними есть почти полная совместимость и последние стандарты стремятся, как могут, друг к другу. А что для этого делается в Rust ?
КД>... было само собой разумеющимся, что иногда в программе будут происходить аварийные остановки.
КД>Это вот наверное хуже всего, когда в неокрепшие мозги закладывают такие допущения. КД>Их потом нереально выковырять обратно. КД>И это касается не только программирования.
+100500
Что значит эти самые "аварийные остановки" Гремлины? Барабашка?
ИМХО это значит только одно: разработчик (или вся команда) не выполнил до конца свою задачу
Есть проблемы — аварийные остановки — смотри лог-файлы и разбирайся в причинах...
Если нужно, то подключай других участников проекта (тех же QA) к локализации проблемы!
Здравствуйте, AlexGin, Вы писали:
AG>ИМХО это значит только одно: разработчик (или вся команда) не выполнил до конца свою задачу
Это значит:
а) Заказчика с его хотелками большими, чем возможно, не послали нахер.
б) Менеджера с его хотелками большими, чем возможно, не послали нахер.
в) Заказчика с его сроками меньшими, чем возможно, не послали нахер.
г) Менеджера с его сроками меньшими, чем возможно, не послали нахер.
д) Вместо использования полноценной СУБД с транзакциями, написанной PhD по computer science, взяли key-value хранилище и стали реализовывать на нём транзакции и прочее силами фронтенд-разработчиков, перешедших в бэкенд на NodeJS. Получилось херово.
е) Вместо использования языков, подходящих для разработки, писали на том, что знают разработчики, получилось херово.
ё) Вместо проверки и доказательства корректности написанного автоматическими средствами, используется вера в разработчика "мамой клянусь, работает".
ж) Вместо того, чтобы использовать средства верификации кода, используется метод пристального прищуренного взгляда и "мамой клянусь, работает".
з) Писали быстрее, чем могут.
Заказчик должен платить деньги и идти нахер. Менеджер должен платить деньги и идти нахер. Выгодополучатели с херовых проектов должны вместо выгоды получать хер на всё рыло, т.е. обычную зарплату, которую они платят разработчикам. Сложные части проектов должны писаться либо людьми с полноценными знаниями — теми, кто SICP прорешал, либо браться в готовом виде, желательно за деньги. Если готовое не удовлетворяет заказчика — заказчик идёт нахер. Почему-то в случае разного рода электротехники заказчиков удовлетворяет готовое и стандартное, а пожелания вида "сделайте мне трансформатор из дерева" посылаются нахер.
Здравствуйте, Pzz, Вы писали:
Pzz>Защита заключается в том, что программа детерминированно сдохнет, вместо того, чтобы недетерменированно делать неизвестно что
Цена вопроса?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, LaptevVV, Вы писали:
LVV>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>И переписать на них все, что можно переписать.
Ну все так все. Почему только Инет ?
Windows скоро перепишут ? Или может, предложим Микрософт реанимировать Singularity ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну все так все. Почему только Инет ? PD>Windows скоро перепишут ? Или может, предложим Микрософт реанимировать Singularity ?
PD>Linux на каком языке переписывать будем ?
Здравствуйте, AlexGin, Вы писали:
AG>+100500 AG>Что значит эти самые "аварийные остановки" Гремлины? Барабашка?
AG>ИМХО это значит только одно: разработчик (или вся команда) не выполнил до конца свою задачу AG>Есть проблемы — аварийные остановки — смотри лог-файлы и разбирайся в причинах... AG>Если нужно, то подключай других участников проекта (тех же QA) к локализации проблемы!
Входных данных у программы может быть миллионы. Всевозможные комбинации выполнения программы вообще сложно представить. А посмотреть лог-файлы и разобраться в причинах — это отладить один какой-то запуск, ну и также некоторые другие похожие. И на всё это уйдёт довольно много времени.
Если пытаться исправить все возможные ошибки, которые могут быть в программе, то может оказаться, что опытной команде не хватит миллиарда лет. То, что программа ни разу не упала, не значит, что она вообще не падает. Отладить на тестах и доказать отсутствие ошибок, это две большие разницы.
Разница как раз в "насильственном насаждении" безопасности растом — в долгосрочной перспективе это хорошо. Можно провести аналогию (лживую, как и другие аналогии) со статической и динамической проверкой типов — хорошее тестовое покрытие динамически типизированного кода вполне ставит его на уровень статического по безопасности. Но когда конпелятор следит — оно всё же надёжнее как-то.
Гремлины? Барабашка? 
