Файлы JPEG несут угрозу ПО Microsoft

 
1 2 3
+
-
edit
 

SAA-977

новичок
Источник: CNews: Файлы JPEG несут угрозу ПО Microsoft

Файлы JPEG несут угрозу ПО Microsoft

Компания Microsoft выпустила «заплатку», которая позволит устранить обнаружившуюся серьезную уязвимость систем безопасности своих программных продуктов при обработке графических файлов формата JPEG, а также настоятельно рекомендует использовать новое средство для выявления уязвимых приложений.

Новая критическая уязвимость сопряжена с особенностями обработки операционной системой Microsoft и другим ПО той же компании графических файлов широко распространенного формата JPEG. Как сообщает Silicon.com, перед злоумышленниками открывается заманчивая возможность создания инфицированных файлов изображений, которые при их простом просмотре смогут самостоятельно запускать на компьютере пользователя вредоносные программы. Обладатели браузера Internet Explorer могут пасть жертвами сетевых преступников, просто попав на сайт с зараженными картинками.

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

«Потенциал для атак крайне высок, - заявил Крейг Шмугар (Craig Schmugar), менеджер группы исследования вирусов компании McAfee. – Тем не менее, пока что мы не видели «тестового» кода». Такой код, позволяющий продемонстрировать возможные способы эксплуатации узявимости злоумышленниками, обычно появляется вскоре после того, как производитель ПО выпускает соответствующее обновление для своего продукта.

Неожиданно выявившаяся «дыра» присуща как минимум десятку программных продуктов производства Microsoft – к ним относятся, в частности, операционные системы Windows XP, Windows Server 2003, браузер Internet Explorer Service Pack 1, пакеты Office XP, Office 2003, Project, Visio, Picture IT и Digital Image Pro – полный перечень можно увидеть на сайте Microsoft. В недавно выпущенном пакете обновления SP2 для Windows XP, который еще предстоит установить многим пользователям системы, эта уязвимость блокирована.

«Опасность состоит в том, что данная уязвимость присуща широкому спектру продуктов», - говорит Стивен Тулуз (Stephen Toulouse), менеджер программ безопасности центра «быстрого реагирования» Microsoft. Широкое распространение уязвимости заставило компанию разработать специальное средство, дающее пользователям Windows Update возможность блокировать уязвимость. Они будут направляться на сайт Office Update, а затем – на специализированный ресурс, который выявит и обновит нуждающиеся в таком обновлении программы и приложения. Данное средство – предвестник новой технологии обновления, которую Microsoft планирует представить в будущем.

«Нам известно, что одно из наиболее важных требований, высказываемых нашими клиентами – упрощение процесса обновления ПО, - говорит г-н Тулуз. В настоящее время мы находим пути унификации механизма обновления».

Разработчикам Linux уже пришлось создать подобный механизм, который позволяет обновить не только ядро операционной системы, но и другие приложения c открытым кодом. Что касается Windows-приложений, то здесь ситуация иная – подавляющее большинство продуктов создано не самой Microsoft, а сторонними разработчиками, что значительно усложняет процедуру организации подобного унифицированного механизма обновления.

«Дыра» в процедуре обработки файлов формата JPEG связана с возможностью исполнения на компьютере пользователя программы, скрытой в самом графическом файле, и не связана с другой, аналогичной уязвимостью при работе с изображениями формата PNG (Portable Network Graphics), выявленной в начале августа 2004 года. Данная уязвимость присуща приложениям, работающим на платформах Linux, Windows и Mac OS X производства Apple. Файлы формата PNG как и JPEG, широко распространены в Сети.

В рамках программы уведомления, реализуемой с апреля 2004 года, все пользователи, заключившие с Microsoft соответствующее соглашение, уже получили предупреждение о «дыре», связанной с JPEG-файлами.

«Некоторые пользователи хотели бы иметь более подробную информацию для планирования своей деятельности», - пояснил г-н Тулуз, отвечая на высказывавшееся в СМИ утверждение о том, что наиболее ценные для Microsoft клиенты получают заблаговременные уведомления о выявленных «дырах». Он порекомендовал интересующимся этими вопросами обращаться за дополнительной информацией к региональным представителям компании. При этом предоставляемая участникам программы информация сводится к количеству «дыр», перечню уязвимых приложений и уровням максимальных угроз.

Связанная с файлами формата JPEG «дыра» – самая новая уязвимость продуктов Microsoft, освещенная в 28-м по счету бюллетене, разосланном компанией в этом году. Зачастую в одном уведомлении Microsoft сообщает о нескольких уязвимостях – так, четыре уведомления, разосланные в апреле, содержали сведения о более чем 20 «дырах».

Вторая «заплатка», выпущенная Microsoft, позволяет устранить уязвимость конвертера файлов WordPerfect в Microsoft Office, Publisher, Word и Works. Данная уязвимость по шкале Microsoft оценена как «важная» - следующий уровень угрозы после максимального – «критического», и позволяет злоумышленникам перехватить управление компьютером пользователя, если тот откроет инфицированный документ формата WordPerfect.

16.09.04, Чт, 15:39, Мск
 
RU Centuriones #16.09.2004 21:33
+
-
edit
 

Centuriones

опытный

А кто нибудь может теперь это перевести на нормальный язык и расшифровать? А то Microsoft все очень туманно и многозначительно, аж оторопь берет к ним на сайт заходить. :blink:
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Centuriones>А кто нибудь может теперь это перевести на нормальный язык и расшифровать?

Жди очередного WindowsUpdate :)

На самом деле - регулярное явление. Даже в этой статье упомянули недавние похожие проблемы с libpng под Linux.

Просто зачем-то нашумели :)
 
RU Centuriones #16.09.2004 22:07  @Balancer#16.09.2004 21:40
+
-
edit
 

Centuriones

опытный

Centuriones>>А кто нибудь может теперь это перевести на нормальный язык и расшифровать?
Balancer>Жди очередного WindowsUpdate :)
Balancer>На самом деле - регулярное явление. Даже в этой статье упомянули недавние похожие проблемы с libpng под Linux.
Balancer>Просто зачем-то нашумели :)[»]

Да нет,я имел ввиду - в чем суть проблемы? Мне, например, непонятно, как графический файл может что-то там запустить?
И кроме того, отчего вообще такие "проколы" появляются на свет? Не в ООП ли тут дело? А это ведь единственное, что роднит Linux, Windows и Mac-OS. Или тут дело в ином?

Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Balancer #16.09.2004 23:13  @Centuriones#16.09.2004 22:07
+
-
edit
 

Balancer

администратор
★★★★☆
Centuriones>Да нет,я имел ввиду - в чем суть проблемы? Мне, например, непонятно, как графический файл может что-то там запустить?

Графический файл обрабатывает программа. Программы нынешние, обычно, пишутся на C/C++, а там есть такой страшный зверь, как переполняемые по границам массивы и указатели. Можно умудриться создать такую картинку, что она выбъет программ-обработчик так хитро, что начнёт исполняться как код участок этой самой картинки.

Centuriones>И кроме того, отчего вообще такие "проколы" появляются на свет? Не в ООП ли тут дело? А это ведь единственное, что роднит Linux, Windows и Mac-OS. Или тут дело в ином?[»]

Как раз не ООП, а дешёвая оптимизация. Введение буферов фиксированного размера, неконтролируемость стека и указателей и т.п.

На настоящих ЯВУ (C#, Java, Ocaml, PHP, Perl и т.п.) таких ошибок допустить сильно сложнее.

В общем-то, давно назрела уже необходимость отправлять C/C++ на почётную пенсию, но наработок под них, наработок... Ситуация на порядки хуже, чем когда-то было с Фортраном :)
 
BG Реконструктор #17.09.2004 11:30  @Balancer#16.09.2004 23:13
+
-
edit
 
Balancer>Графический файл обрабатывает программа. Программы нынешние, обычно, пишутся на C/C++, а там есть такой страшный зверь, как переполняемые по границам массивы и указатели. Можно умудриться создать такую картинку, что она выбъет программ-обработчик так хитро, что начнёт исполняться как код участок этой самой картинки.

Полный абсурд. В НТ системах права на память очень рестриктивные. Запрос на буфер стандартными средствами дает тебе участок памяти, который не имеет права на выполнение кода, т.е. попытка выполнить там код заканчивается exception-ом. Чтоб выполнить там код надо этот участок дополнительно обработать. Я очень сильно сомневаюсь, что программисты специально давали буфферам для обработки JPEG-ов права на выполнение.
Вооще статия - чушь.

Balancer>В общем-то, давно назрела уже необходимость отправлять C/C++ на почётную пенсию, но наработок под них, наработок... Ситуация на порядки хуже, чем когда-то было с Фортраном :)[»]

Пока не появится 15000 ГГц 1024 бит Пентиум-57, этого не произойдет. Так что C/C++ будет жить еще много.

 

hcube

старожил
★☆

Эээ.... так надо больно бить программиста, который такой код написал. AFAIK размер картинки лежит в JPG в самом начале, по этому размеру элементарно определяется максимальный размер файла, и все - никаких выездов за границу этого массива просто нельзя допускать, и все. Блин, когда-то я думал, что Windows надежная система. Теперь, после того как вирусы пролезают в систему за среднее время в 10 минут, я уже ни в чем не уверен.
Убей в себе зомби!  

Vale

Сальсолёт

>В общем-то, давно назрела уже необходимость отправлять C/C++ на почётную пенсию

Давно компилировал что-нить с помощью GCC?
В последних версиях - постоянные напоминания - "эта функция небезопасна...."
на strcpy gets etc.
"Не следуй за большинством на зло, и не решай тяжбы, отступая по большинству от правды" (Исх. 23:2)  
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>Запрос на буфер стандартными средствами дает тебе участок памяти, который не имеет права на выполнение кода

Сходи в "Система -> Свойства -> Дополнительно -> Быстродействие -> Предотвращение исполнения данных" и почитай описание DEP. Даже мой P IV ещё не допускает аппаратной его поддержки. А программная - это тормоза и глюки. И потому по дефолту всегда выключена.

Реконструктор>т.е. попытка выполнить там код заканчивается exception-ом.

Тогда ещё раз перечитай эту новость :)

Реконструктор>Пока не появится 15000 ГГц 1024 бит Пентиум-57

Ты тесты на скорость на чисто вычислительных задачах смотрел в форуме "Forth"? Смотрел, я помню твои постинги. Так что ты тогда бред несёшь? :) C# и Java уступают чистому C++ лишь проценты, а Ocaml - обгоняет C++.
 
+
-
edit
 

Balancer

администратор
★★★★☆
hcube>Эээ.... так надо больно бить программиста, который такой код написал.

Приучать к культуре программирования такими методами бессмысленно и бесполезно. Опасный код писали, пишут и будут писать на всех платформах. Единственный способо бороться с этим в массах - создавать более защищённые языки.

hcube>Блин, когда-то я думал, что Windows надежная система. Теперь, после того как вирусы пролезают в систему за среднее время в 10 минут, я уже ни в чем не уверен.[»]

Надёжных систем вообще в природе нет. И чем система сложнее, тем менее она надёжна. В тех же Linux-системах кажды день находят дырки. Пару раз в месяц - дырки серьёзные, например, позволяющие запустить код удалённо (локальные уязвимости менее критичны). Если б Linux был столь же распространён, как и Windows - его бы тоже имели бы и в хвост и в гриву :)

Vale>Давно компилировал что-нить с помощью GCC?

Вчера пара компиляций на GCC 4.3.2

Vale>В последних версиях - постоянные напоминания - "эта функция небезопасна...."

Вот именно. Постоянные напоминания. И что? Это заставит программистов отказаться от них? :)

Vale>на strcpy gets etc.[»]

Это проблема не функций, а языка. Эти же функции на C# или PHP (на нём - вообще прямые аналоги) безопасны. Или на том же Ocaml :) И если скорость PHP тут не позволяет его ставить в один ряд с C++, то C# имеет скорость нативного кода того же уровня, даже на опенсорсном mono, а Ocaml в среднем быстрее.
 

Vale

Сальсолёт

Это таки проблемы библиотек.
Есть такой класс -AnsiString ;) , к примеру...





"Не следуй за большинством на зло, и не решай тяжбы, отступая по большинству от правды" (Исх. 23:2)  
+
-
edit
 

Balancer

администратор
★★★★☆
Vale>Это таки проблемы библиотек.

Это таки проблемы языка. Язык позволяет писать безопасно, но позволяет и опасно. При чём опасно - сильно проще. Потому писали, пишут и будут писать опасно.

А в безопасных изначально языках - и библиотеки безопаснее :)

А так - безопасно и на ассемблере писать можно. Вопрос только в цене.
 

Vale

Сальсолёт

Кроме того, жизнь меня учит, что переносимость кода есть плюс.
Я одни и те же модули на плюсах использую в DOS 16 и 32 бит, Windows 32 бит и ещё в Linuх.

Кто-нить видел С# для DOS? :uhaha:
"Не следуй за большинством на зло, и не решай тяжбы, отступая по большинству от правды" (Исх. 23:2)  

Balancer

администратор
★★★★☆
Vale>Кто-нить видел С# для DOS? :uhaha:[»]

Хм... Дай вспомнить... DOS я видел, кажется, года 4 назад мельком. И даже на QB45 что-то минут 5 для него писал :D

Очень актуально! :)

И что, кстати, все безопасные библиотеки классов C++ под DOS пашут?? :D

А так - мне достаточно того, что C# программы работают на Win32, Linux, MacOS и карманных ПК с ARM, MIPS и SH3 процессорами :)

Опять же, тут Гриша про скорость интересовался. Вот скомпилирована у меня C++ либа под i386 и что толку от её оптимизации на AMD64 будет? А на StrongARM она вообще не пойдёт... В отличие от :)

Да... DOS... Ещё давай CP/M вспомним... помянем... :)
 
RU Centuriones #17.09.2004 12:54
+
-
edit
 

Centuriones

опытный

Всетаки я так и не врубился, как происходит, что с определенного момента данные вдруг начинают интерпретироваться как команды. Ведь для этого как-то надо передать управление на нужный адрес в памяти. Так ведь?
Можно ли привести пример?
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Balancer #17.09.2004 13:00  @Centuriones#17.09.2004 12:54
+
-
edit
 

Balancer

администратор
★★★★☆
Centuriones>Всетаки я так и не врубился, как происходит, что с определенного момента данные вдруг начинают интерпретироваться как команды.

Именно так. Ведь и то и другое - байты. А в плоской модели памяти сегментные регистры указывают на одну область памяти.

Centuriones>Ведь для этого как-то надо передать управление на нужный адрес в памяти. Так ведь?

Да.

Centuriones>Можно ли привести пример?[»]

Точный пример сочинять лень, тем более, что практикой переполнения буферов сам не занимался. Но вот такой гипотетический пример. Программы каждый раз грузятся с одних адресов. При одних исходных данных эти данные тоже программа положит в одни и те же адреса. Пусть у нас там где-то хранится и исполняемый код. Выделенные массивы C++ хранит на общем стеке - данных-возврата. В программе есть ошибка, не контролирующая границы массивов. Пользуемся этой ошибкой и переполняем отведённый под данные буфер, залезая в стек возвратов. Заполняем массив данными так, чтобы адрес возврата из подпрограммы оказался затёрт нашим адресом. Подпрограмма заканчивает работу, процессор осуществляет команду возврата. Вот только адрес в стеке уже не оригинальный, а наш.
 
BG Реконструктор #17.09.2004 13:01  @Balancer#17.09.2004 12:14
+
-
edit
 
Balancer>Сходи в "Система -> Свойства -> Дополнительно -> Быстродействие -> Предотвращение исполнения данных" и почитай описание DEP. Даже мой P IV ещё не допускает аппаратной его поддержки. А программная - это тормоза и глюки. И потому по дефолту всегда выключена.

Что это?

Balancer>Ты тесты на скорость на чисто вычислительных задачах смотрел в форуме "Forth"? Смотрел, я помню твои постинги. Так что ты тогда бред несёшь? :) C# и Java уступают чистому C++ лишь проценты, а Ocaml - обгоняет C++.[»]

Вычислительные задачи - это не все. Ц#, например (а и многие другие), допускает боксинг. Неумелый программист (которые обычно пользуются такими языками), может неосознанно сделать программу в тысячу раз медленее. В ц++ боксинг можно сделать тоже, но я не видел чтоб кто-нибудь реально в практике занимался этим. Вообще, Ц++ заставляет более углубленно продумывать программы, от того и работают они быстрее.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>Что это?

Хм. То ты мне про защиту в ОС от выполнение кода в области данных пишешь, то тут же спрашиваешь, что это такое. К тому же я тебе сказал куда смотреть. Вот оттуда хелп:
Understanding Data Execution Prevention

Understanding Data Execution PreventionData Execution Prevention (DEP) helps prevent damage from viruses and other security threats that attack by running (executing) malicious code from memory locations that only Windows and other programs should use. This type of threat causes damage by taking over one or more memory locations in use by a program. Then it spreads and harms other programs, files, and even your e-mail contacts.

Unlike a firewall or antivirus program, DEP does not help prevent harmful programs from being installed on your computer. Instead, it monitors your programs to determine if they use system memory safely. To do this, DEP software works alone or with compatible microprocessors to mark some memory locations as "non-executable". If a program tries to run code—malicious or not—from a protected location, DEP closes the program and notifies you.

DEP can take advantage of software and hardware support. To use DEP, your computer must be running Microsoft Windows XP Service Pack 2 (SP2) or later, or Windows Server 2003 Service Pack 1 or later. DEP software alone helps protect against certain types of malicious code attacks but to take full advantage of the protection that DEP can offer, your processor must support "execution protection". This is a hardware-based technology designed to mark memory locations as non-executable. If your processor does not support hardware-based DEP, it's a good idea to upgrade to a processor that offers execution protection features.
 


Реконструктор>Вычислительные задачи - это не все. Ц#, например (а и многие другие), допускает боксинг. Неумелый программист (которые обычно пользуются такими языками), может неосознанно сделать программу в тысячу раз медленее.

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

>В ц++ боксинг можно сделать тоже, но я не видел чтоб кто-нибудь реально в практике занимался этим.

Так зачем на C# будут этим заниматься? :D Или чем неумелый программист на C# хуже неумелого программиста на C++? Тем, что ему компилятор не позволит совершить кучу рантаймовских ошибок, которые пройдут в C++? :D

И, вообще, давай пример - измерим реальное падение производительности. Я очень сомневаюсь про 1000 раз :D

>Вообще, Ц++ заставляет более углубленно продумывать программы

Можно пример? А то моя практика об обратном говорит :) В C++ больше внимания уделяешь не алгоритму, а реализации. А это - всегда хуже. Ещё во времена программируемых калькуляторов гуру учили - "не экономьте одну команду, экономьте сразу пятьдесят".

Чем выше уровень языка, тем больше внимания можно уделить глобальной оптимизации. И выигрышь на этом будет не в проценты, а в порядки :)
 
BG Реконструктор #17.09.2004 13:22  @Balancer#17.09.2004 13:00
+
-
edit
 
Balancer>Точный пример сочинять лень, тем более, что практикой переполнения буферов сам не занимался. Но вот такой гипотетический пример. Программы каждый раз грузятся с одних адресов. При одних исходных данных эти данные тоже программа положит в одни и те же адреса. Пусть у нас там где-то хранится и исполняемый код. Выделенные массивы C++ хранит на общем стеке - данных-возврата. В программе есть ошибка, не контролирующая границы массивов. Пользуемся этой ошибкой и переполняем отведённый под данные буфер, залезая в стек возвратов. Заполняем массив данными так, чтобы адрес возврата из подпрограммы оказался затёрт нашим адресом. Подпрограмма заканчивает работу, процессор осуществляет команду возврата. Вот только адрес в стеке уже не оригинальный, а наш.[»]

Проблемма переполнения существовала лет десять назад. Она, конечно, и сейчас существует, но только в практике начинающих юношей, которым, я пологаю, надо пройти долгий путь к воторам М$.
Дело вот в чем. Имеется дурная привычка декларировать массивы в стеке, вместо того, чтоб заказывать их у хийпа. Вот, например, у нас ф-я.

code text
  1. int CalcSomeVeryComplicatedThing(InputStruct* input)
  2. {
  3. SomeOtherFunc* func = &MyFunc;
  4. char temp_buff[1024];
  5.  
  6. ...
  7.  
  8.  
  9. }


Если произойдет сбой обрабатюещего алгоритма и он, скажем, запишет 4 байта после temp_buff (адреса temp_buff[1024, 1025, 1026, 1027]), то эти данные уйдут как раз в переменную func, и при выполнении этой ф-ии процессор переидет на адрес, указанный теми 4-мя байтами. Дела в том, что стек-то один, и ОС, конечно, не может разобратся пишеш ли ты после temp_buff[1023] или пишеш в func, для нее это одно и то-же.
Однако, когда буфер заказан у хийпа, т.е. temp_buff = new char[1024], то такое невозможно, така как каждое обращение вне пределах массива кончается ексепшеном.
 
BG Реконструктор #17.09.2004 13:34  @Balancer#17.09.2004 13:08
+
-
edit
 
Balancer>Хм. То ты мне про защиту в ОС от выполнение кода в области данных пишешь, то тут же спрашиваешь, что это такое. К тому же я тебе сказал куда

Ну, это мне не известно. Вообще-то в окнах защита встроенная, вот, читай, если не лень.

Когда заказываеш у хийпа буффер, то он имеет права PAGE_READWRITE. Чтобы выполнить в нем код, надо разширить права до PAGE_EXECUTE.

Balancer>А неумелый программист на C++ может сделать программу в 1000 раз медленнее, чем программист на ассемблере. Однако это не помешало людям быстренько переползти на C++

Нет, не правда. Язык Ц, в целом, не очень далеко от макроассемблера. Это и причина "быстрого переползания". :)

Balancer>Так зачем на C# будут этим заниматься? :D Или чем неумелый программист на C# хуже неумелого программиста на C++? Тем, что ему компилятор не позволит совершить кучу рантаймовских ошибок, которые пройдут в C++? :D
Balancer>И, вообще, давай пример - измерим реальное падение производительности. Я очень сомневаюсь про 1000 раз :D
>>Вообще, Ц++ заставляет более углубленно продумывать программы
Balancer>Можно пример? А то моя практика об обратном говорит :) В C++ больше внимания уделяешь не алгоритму, а реализации. А это - всегда хуже. Ещё во времена программируемых калькуляторов гуру учили - "не экономьте одну команду, экономьте сразу пятьдесят".
Balancer>Чем выше уровень языка, тем больше внимания можно уделить глобальной оптимизации. И выигрышь на этом будет не в проценты, а в порядки :)[»]

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

 
RU Balancer #17.09.2004 15:24  @Реконструктор#17.09.2004 13:34
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>Проблемма переполнения существовала лет десять назад. Она, конечно, и сейчас существует, но только в практике начинающих юношей

Ок. Тогда остаётся признать, что нынешние ведущие программисты многих крупных проектов - начинающие юноши :)

Реконструктор>Ну, это мне не известно. Вообще-то в окнах защита встроенная, вот, читай, если не лень.

Остаётся удивиться, почему в том же MS программисты - такие неумехи :)

А про переносимость такого кода я вообще молчу :)

Реконструктор>Нет, не правда. Язык Ц, в целом, не очень далеко от макроассемблера. Это и причина "быстрого переползания". :)

Ну, здрасьте-приехали!
Жаль, под рукой нет C++ компайлера (кстати, вот ещё один плюс C# - его компайлер в любой системе с .NET есть, благо весит он копейки), а то б я тебе сейчас подобрал примерчик :)

Реконструктор>Давай для начала, ты знаеш что такое боксинг? Давай сначало про него, а потом я тебе расскажу про некоторые особенности языка VB, которые мне причинили много гемороя (когда-то).[»]

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

Потому что даже в таком совершенно идиотском примере:
Пример C# идиотский [показать]


в сравнении с таким кодом C++, как

Пример С++ [показать]


Проигрыш составляет всего в шесть раз (43.5 против 7.0сек.)
Это при том, что код совершенно идиотский и без учёта боксинга :)

Так что пока ты врёшь, как минимум, на два с лишним порядка в своих оценках :)

А в реальном программировании разница будет куда меньше, т.к. боксинг тут понятие крайне искуственное и придумать что-то подобное - это уже совсем идиотом нужно быть :)
 
RU Филич #17.09.2004 16:12
+
-
edit
 

Филич

втянувшийся

еднственное, где может быть проблема - сегмент СОМ, комментарии. в файле это просто поток байт с определенной длиной. если туда запрятать что то, что может вызвать программу для обработки этого чего то (например, скрипта) только тогда возникает опасная ситуация.
про защиту памяти совершенно верно указано. данные в исполняемый код сами по себе, в результате ошибки переполнения никак не смогут попасть.
существуют только два типа кораблей: подводные лодки и их цели
 
BG Реконструктор #17.09.2004 16:43
+
-
edit
 
Balancer>Нет, ты мне давай конкретный пример, где начинающий программер применит боксинг, который сделает задачу на три порядка тормознее.

Ну, не понимаеш когда образно говорю. :)

Во-первых, вот настоящий боксинг, вполне реальная ситуация. Видел такие, подобное иногда творят пришельцы из безтипных языков, типа ПХП.


code text
  1. int fib(object n)
  2. {
  3.         int N = (int)n;
  4.         if (N < 2)
  5.         {
  6.                 return 1;
  7.         }
  8.         else
  9.         {
  10.                 return fib(N-1) + fib(N-2);
  11.         }
  12. }


Во вторых, результаты у меня не много иначе.
На фиб(40):
C++ : 2.7 сек
C# : 33.9 сек

Так что разница более чем порядок.

И под конец, фунция без боксинга (т.е. int fib(int n)) дает 27.1 сек. т.е. не слишком быстрее боксинга. :)

Вывод: Ц# мастдай. Игрушка для юношей. И хватит тебе всякую чепуху защищать. :)
 
+
-
edit
 

tarasv

опытный

>Вывод: Ц# мастдай. Игрушка для юношей. И хватит тебе всякую чепуху защищать.

Надо сказать что для вычисляторных задач мастдай а для коммерческих с БД какраз плюсы мастдай и ИМХО гораздо более полный чем жаба или сишарп для вычисляторных.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>И под конец, фунция без боксинга (т.е. int fib(int n)) дает 27.1 сек. т.е. не слишком быстрее боксинга. :)

Глючишь :) Давай аттачи с exe-шниками, проверю :)
Вот мои варианты (fib(42))
5.3 против 6.3 у C#
Твой вариант с боксингом - 14.7сек.
Всего 2.8 раза проигрышь
При чём задача - ну наивычислительнейшая! :)

Ну и до кучи - OCaml. 4.6 сек :D
C++ перед OCaml по скорости такой же "отстой", как C# перед C++ :D
Только Ocaml - это совершенно иной уровень :)

Реконструктор>Вывод: Ц# мастдай.

Вывод - кто-то считать не умеет :D
В общем, я приложил аттачи. Готовые exe-шники и исходники.

Ы. Кстати. М.б. ты без ключика /optimize на C# компилил? :D
Так и C++ без оптимизации ещё и не такое покажет :)
Прикреплённые файлы:
fib42_vc7.zip (скачать) [15,12 кбайт, 18 загрузок] [attach=27022]
 
fib42_csharp.zip (скачать) [1,66 кбайт, 15 загрузок] [attach=27023]
 
fib42_csharp_boxing.zip (скачать) [1,75 кбайт, 25 загрузок] [attach=27024]
 
fib42_ocaml.zip (скачать) [94,16 кбайт, 25 загрузок] [attach=27025]
 
 
 
1 2 3

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru