> Блин, еще один. Причем тут это-то? Давай ты приведешь свою цепочку доказательств того, что C подходит под задачу написания прикладного софта и мы вместе посмеемся.

ммм.. вам хочется просто поpi%$ или все-таки ехать? "солнце всходит и заходит.."

// wbr

>ммм.. вам хочется просто поpi%$ или все-таки ехать? "солнце всходит и заходит.."

Ну ты хитрый какой. Т.е доказательств не будет?

> Ну ты хитрый какой. Т.е доказательств не будет?

я за презумпцию невиновности. пока что аргументов кроме "нуу.. у девелУперов кривые руки" я не видел. это за доказательство не считается. в лучшем случае - ограничивающий фактор.

// wbr

Version Control System Comparison

разбавлю флейм полезной ссылкой:

Version Control System Comparison
http://better-scm.berlios.de/comparison/comparison.html

>я за презумпцию невиновности. пока что аргументов кроме "нуу.. у девелУперов кривые руки" я не видел. это за доказательство не считается. в лучшем случае - ограничивающий фактор.

Ты наверное плохо смотрел. Глянь заголовок новости. Также я не зря давал ссылку на debian.org, посмотри список последних найденных ошибок, погляди на чем писаны приложения. Потом возвращайся с накопленным результатом, обсудим.

> Ты наверное плохо смотрел. Глянь заголовок новости.

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

> Также я не зря давал ссылку на debian.org, посмотри список последних найденных ошибок, погляди на чем писаны приложения.

на Debian не пойду бо Linux не использую. если хотите обсудить примеры со ссылкой на конкретную систему, то мне проще в терминах BSD.

> Потом возвращайся с накопленным результатом, обсудим.

что "язык C не подходит для написания приложений?". извините, но это я обсуждать не буду - это чистой воды словоблудие :)

// wbr

> $ cd /usr/src/sys/

Это не прикладное. Это системное ;)

> Это может быть любой другой язык: Clean, OCaml, Python, Scheme, Java, VB.NET, Bash scripts, Tcl. Если я не ошибаюсь, ни в одном из них получить дыру в безопасности переполнением буфера нельзя.

ну насчет шелл-скриптов -- там можно огрести такую кучу ошибок и еще больше дыр, что C и не снилось.

С не защищаю, но нигде в стандарте не сказано, что нельзя автоматом проверять границы массивов. Пропатчи компилятор или неисполнимый стек сделай.. Или═пусть компилятор по другому стек располагает.

Сабж! Антон, какие планы на этот раз ;)

> Version Control System Comparison

там clear case не хватает..

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

Ошибаешься, т.к. принимаешь за аксиому безошибочность работы с памятью
в этих языках. В них самих может быть проблема с переполнением буфера
в их внутреннем коде, что не раз подтверждалось на практике - perl,
python, php и т.д.

> Бля урод! Сказали тебе умные люди ПОЧЕМУ ЭТО ВЫЛЕЗЛО.

Ты правда считаешь, что объяснения неких умных людей как-то поможет вернуть 8.5 млрд. баксов, потерянных из-за ошибки в программе на Ada? По-моему, эти объяснения просто никого не волнуют. И ещё после таких ошибок ни одна вошь, типа тебя не имеет права называть Ada безопасным языком. И кстати, ни один по-настоящему умный человек не скажет тебе, что Ada - безопасный язык. Ты сильно увлекаешься бульварной околокомпьютерной прессой.

>ну насчет шелл-скриптов -- там можно огрести такую кучу ошибок и еще больше дыр, что C и не снилось.

Это другой вопрос.

>С не защищаю, но нигде в стандарте не сказано, что нельзя автоматом проверять границы массивов. Пропатчи компилятор или неисполнимый стек сделай.. Или═пусть компилятор по другому стек располагает.

А это демагогия. Какая разница, что моглы бы? Де факто мы имеем постоянные дыры из-за переполнения буфера (но это не единственный источник ошибок, разумеется)

>Ошибаешься, т.к. принимаешь за аксиому безошибочность работы с памятью в этих языках. В них самих может быть проблема с переполнением буфера в их внутреннем коде, что не раз подтверждалось на практике - perl, python, php и т.д.

Ну дык о том и реь. Сами они на чем написаны? :)

>Ты правда считаешь, что объяснения неких умных людей как-то поможет вернуть 8.5 млрд. баксов, потерянных из-за ошибки в программе на Ada?

Кончай апелировать к эмоциям. Ты можешь сходу оценить выгоду использования Ада вместо C? Или потери из-за ошибок C? Или потери/выгоду из-за использования C вместо другого языка? Или что было бы, если на месте Ada использовался C?

Я - нет, а поэтому это словоблудие насчет "миллиардов баксов" меня мало волнует. Все познается в сравнении. Ну потеряли и потеряли. Ошибки-то все равно люди делают.

И кстати, ты путаешь причину со следствием. Ошибка была совершена на языке Ada скорее всего потому что многих других языков там и рядом не лежало. Я думаю, стоимость всех ошибок всех программ на GW-Basic-е существенно ниже этих $8.5 млрд, однако это не говорит о надежности GW-Basic-а. Поэтому так же не говорит о надежности Ada ошибка в $8.5 млрд. Понимаешь логику? Это одиночный замер и делать на основании него какие-либо выводы, без знания деталей, - глупо.

>По-моему, эти объяснения просто никого не волнуют. И ещё после таких ошибок ни одна вошь, типа тебя не имеет права называть Ada безопасным языком.

>И кстати, ни один по-настоящему умный человек не скажет тебе, что Ada - безопасный язык. Ты сильно увлекаешься бульварной околокомпьютерной прессой.

По сравнению с C Ada бесспорно безопасней. Я где-то видел статистику по среднему количеству ошибок на строчку кода, если найду - покажу.

>А это демагогия. Какая разница, что моглы бы? Де факто мы имеем постоянные дыры из-за переполнения буфера (но это не единственный источник ошибок, разумеется)

Тут я, конечно, совершенно не прав.

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

>если говорить о новости, то см. самое первое сообщение в потоке. ссылку на грамотное описание уязвимости в студию. можно без exploit.

Не важно. Речь о переполнениях буфера в целом. Я зря сослался на саму новость, согласен. Ситуация с переполнением в CVS пока не совсем ясна (можно еще тут посмотреть https://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.116.2.127&content-...), но это не важно. Постоянные переполнения буфера - это реальность :)

>на Debian не пойду бо Linux не использую. если хотите обсудить примеры со ссылкой на конкретную систему, то мне проще в терминах BSD.

Да без разницы, я debian.org привел просто потому что это удобное место для просмотра всячеких уязвимостей. Вот, глянь: http://www.debian.org/security/2005/

Заметь, что эти уязвимости не специфичны для Debian, тот же софт используется и во многих других системах. Посчитай количество buffer overflow.

Могу еще вот эту ссылку дать: http://www.frsirt.com/english/index.php

>что "язык C не подходит для написания приложений?". извините, но это я обсуждать не буду - это чистой воды словоблудие :)

Ну вот - уже словоблудие. Нормальное обсуждение :) Возможно, слишком субъективное, так как не было зафиксировано понятие "нормально подходит".

> Ты можешь сходу оценить выгоду использования Ада вместо C?

Я нигде ни словом не обмолвился про Си. Я лишь выступил оппонентом
против высказывания "На Ada ничего подобного невозможно".

> словоблудие насчет "миллиардов баксов" меня мало волнует.

Словоблудие у тебя. У меня факт.

> Ошибка была совершена на языке Ada скорее всего потому что многих других языков там и рядом не лежало.

Опять ошибаешься. Читай до полного просветления:
http://www.rol.ru/news/it/press/cwm/38_97/ariane.htm

> Это одиночный замер

Это могильная плита на которую все называющие себя программистами
должны смотреть время от времени и никогда не произносить бред про
супернадёжность Ada, который тут прозвучал выше.

>Я нигде ни словом не обмолвился про Си. Я лишь выступил оппонентом против высказывания "На Ada ничего подобного невозможно".

_подобного_ невозможно. Речь шла о переполнении буфера.

>Опять ошибаешься. Читай до полного просветления: http://www.rol.ru/news/it/press/cwm/38_97/ariane.htm

Ключевой момент:

[...] Однако адаптация ПО для проекта Ariane 5 прошла без должной ревизии уже созданных программных строительных блоков. К сожалению, сделанные в них допущения противоречили спецификациям новой программы полета. [...]

Эта ошибка скорее всего могла быть обнаружена формальной верификацией программы. Причем тут язык Ada? Я бы еще понял, если бы речь шла о верификации программ в контексте Ada, однако этого же не было.

>Это могильная плита на которую все называющие себя программистами должны смотреть время от времени и никогда не произносить бред про супернадёжность Ada, который тут прозвучал выше.

Бред. С таким же успехом это мог бы быть любой язык.

Кстати, где ты увидел речь про супернадежность? Не было ничего про супернадежность, была реплика о том, что на Ada такое (переполнение буфера) получить невозможно. Точка. Вместо этого ты влез с красными глазами и начал приводить пример, совершенно нерелевантный дискуссии. Более того, даже если расширить границы дискуссии до надежности различных языков в целом, этот пример все равно ничего не доказывает - так как нет сравнения с другими языками.

>>Ошибка была совершена на языке Ada скорее всего потому что многих других языков там и рядом не лежало.

>Опять ошибаешься. Читай до полного просветления: http://www.rol.ru/news/it/press/cwm/38_97/ariane.htm

Что-то я не нашел там опровержения своим словам. Например, я на 100% уверен, что Java там не было и поэтому у просто Java не было никаких шансов проявить себя таким образом :) Вот это-то я и хотел сказать.

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

>8.5 млрд. баксов, потерянных из-за ошибки в программе на Ada?


ТЫ, микроб, можешь мне объяснить суть этой ошибки? Не можешь? Тогда не 
вякай. Я те объясню. Такого рода конвертацию в Ada можно сделать только 
с использованием Unchecked_Conversion - простое приведение типов вроде 

1) Integer16(Float64) - недаст сделать компилятор, поэтому
   было сделано Unchecked_Conversion.
2) Из экономии НЕБЫЛО КОДА, отлавливающего возможное исключение 
   Operand_Error, которое возникает при невозможности провести 
   преобразование. 

И нах. со своими ссылками на всяких мудаков. Читай источник.

http://sspg1.bnsc.rl.ac.uk/Share/ISTP/ariane5rep.htm

Вывод таков:
Компилятору заткнули рот Unchecked_Conversion-ом, а обработчики 
исключений были не использованы НАМЕРЕННО, т.к. на 4-м Arian-е такая 
ситуация просто физически возникнуть не могла.

The reason for the three remaining variables, including the one 
denoting horizontal bias, being unprotected was that further reasoning
indicated that they were either physically limited or that there was a
large margin of safety, a reasoning which in the case of the variable 
BH turned out to be faulty. It is important to note that the decision 
to protect certain variables but not others was taken jointly by 
project partners at several contractual levels.

>И кстати, ни один по-настоящему умный человек не скажет тебе, что Ada 
- безопасный язы


Ты это про себя? Нах!


>Ты сильно увлекаешься бульварной околокомпьютерной прессой.


В натуре? Ошибаешся. Я давно и успешно делаю программы на Ada.

Потявкаешь еще?

>Я нигде ни словом не обмолвился про Си. Я лишь выступил оппонентом >против высказывания "На Ada ничего подобного невозможно".

Похоже я неточно выразился - фраза должна была звучать так "На Ada переполнение буфера можно устроить, но для этого надобно СИЛЬНО постараться и точно знать что ты делаешь - т.е. СПЕЦИАЛЬНО ДЕЛАТЬ ИМЕННО ПЕРЕПОЛНЕНИЕ БУФЕРА". Более того, если начинающему программисту на Ada предложить сделать переполнение буфера - он будет долго думать как это устроить и скорее всего у него не получится.

плохой из тебя фраг. то что больше уязвимых аппсов на си - это потому что на нем 90% всего пишется

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

да. потому паскаль и ада - языки для обучения программированию =) получению экспириенса. ну как курс по ВВ для саперов

>плохой из тебя фраг.

Это сокращение от Walking Frag, если что :)

>то что больше уязвимых аппсов на си - это потому что на нем 90% всего пишется

Не, речь про переполнение буфера. Хрен с ними, с другими ошибками, речь пока не о них. Меня смущает количество ошибок безопасности из-за переполнения буфера. Как-то их много слишком.

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

Честно скажу - Ada-у только в книжке видел :) Моя позиция немного не о том. А хлеб я кухонным ножом режу, а не бензопилой "Дружба", как раз чтобы ногу себе не отпилить случайно :)

Ну вот нафиг в большинстве задач низкоуровневая работа с памятью? Возьмем, например, Subversion. Там основная семантика - это всяческие манипуляции с деревьями, изменениями, etc. Зачем там тонкая работа с памятью?

> подобного_ невозможно. Речь шла о переполнении буфера.

Ну что за детские отмазки? Кому интересен какой-то buffer overflow сам по себе? Трогает лишь эффект от него. Дык подобный эффект и был показан.

> 2) Из экономии НЕБЫЛО КОДА, отлавливающего возможное исключение
Operand_Error, которое возникает при невозможности провести
преобразование.

Вывод нормального человека из вышесказанного таков: в Ada нет реальной
защиты от ошибки программиста. Вывод фаната Ada: язык не при чём,
виноваты космические лучи.

>Вывод нормального человека

Вывод ПРИДУРКА с которым разговаривать совершенно бесполезно.

Адью красавчик.

>Ну что за детские отмазки? Кому интересен какой-то buffer overflow сам по себе? Трогает лишь эффект от него. Дык подобный эффект и был показан.

Ты это, от темы не уходи. Моя цель не пиписьками померяться и выяснить кто прав, а кто нет, а обозначить некоторую проблему, предложить способы ее решения и обсудить это.

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

>Трогает лишь эффект от него.

Кто сказал? Я начинал дискуссию только относительно ошибки переполнения, а не эффектов от различных ошибок в целом. И это не отмазка, а попытка удержать дискуссию в некотором русле. Собственно, на данный момент я вижу, что дискуссия по-видимому себя исчерпала и ее можно спокойно закончить.

> Остальные ошибки кроме переполнения буфера я на данный рассматривать не хочу

Вот от таких товарисчей и заваливаются ракеты Ариан. Потому как мышление их однобоко: нет buffer overflow? - безопасен, можно расслабиться. И всё-таки ошибка была того же порядка и того же класса. Недосмотр, превышение границ.

>Вот от таких товарисчей и заваливаются ракеты Ариан. Потому как мышление их однобоко: нет buffer overflow? - безопасен, можно расслабиться. И всё-таки ошибка была того же порядка и того же класса. Недосмотр, превышение границ.

Ну ты странный какой-то. Я не господь бог и решить _все_ проблемы этого мира начиная от негров и кончая ракетами я не могу (и ты тоже). И даже обсудить не могу. Именно по этому я хочу ограничить тему узкими рамками, чтобы было ясно когда все аргументы перечислены и стоит закончить разговор. Тема, навеянная новостью - ошибки безопасности из-за переполнение буфера и язык C в прикладном программном обеспечении. Заметь, ракеты мы пока не запускаем. Более того, я не говорю, что остальные ошибки в прикладном софте можно игнорировать - они несомненно тоже важны. Но я выделил именно ошибку переполнения буфера так как встречается она ну уж очень часто. Вопросы по постановке задачи есть?

И не надо мне приписывать того, что я не говорил. Я не говорил, что если нет переполнения буфера, то можно сразу в космос запускать. Я вообще рассматривал отдельно взятую проблему. Это называется не однобокое мышление, а рамки обсуждения. Без их установки разговор рано или поздно выливается в разговор ни о чем (или обо всем сразу).

Если тебе интересно обсудить ошибку переполнения - открывай отдельную тему.

Все, я больше не хочу говорить на эту тему.

>Если тебе интересно обсудить ошибку переполнения - открывай отдельную тему.

Великий и могучий русский язык сыграл со мной злую шутку :) Я имел ввиду переполнения, связанные с конверсией типов, ну и вообще с числовыми операциями в целом.