Компания Coverity, развивающая инструментарий для автоматического анализа кода на предмет наличия проблем безопасности и ошибок представила (http://www.bradenton.com/2012/02/23/3896742/open-source-code...) очередной ежегодный
отчёт (http://www.coverity.com/library/pdf/coverity-scan-2011-open-...) (PDF, 550 Кб) с результатами изучения 37 млн строк кода из 45 наиболее активно разрабатываемых открытых проектов и 300 млн строк кода из 41 анонимного проприетарного продукта. В среднем, в открытых проектах было выявлено 0.45 дефектов на 1000 строк кода, для проприетарных продуктов данный показатель составляет 0.64, при этом средний показатель качества для всей индустрии разработки ПО составляет 1 ошибка на 1000 строк кода.Система Coverity Scan была создана в 2006 году по инициативе Министерства национальной безопасности США для обеспечения и усиления безопасности информационной инфраструктуры Соединенных Штатов, в которой используются различны...
URL: http://www.bradenton.com/2012/02/23/3896742/open-source-code...
Новость: http://www.opennet.ru/opennews/art.shtml?num=33188
Нормально так. Все ошибки показательны для языков программирования C, C++ и являются их генетическими дефектами. Как вывод: большие проекты на C,C++ неизбежно будут страдать от ошибок программиста отслеживать в ручную управлением памятью и пр.
> страдать от ошибок программиста отслеживать в ручную управлением памятью и пр.Ну хорошо, а большие проекты вебни страдают от CSRF, XSS, insecure data handling во всех ипостасях, SQL-иньекций, ошибок разграничения доступа, ... - ну что, вам полегчало, да? :)
интересно что используя нормальные Фрэймворки -- довольно сложновато допустить: CSRF, SQL-Inj, XSS1. CSRF
...например -- в Django сделать CSRF ошибку -- по сути можно только если НАСИЛЬНО отключить CsrfViewMiddleware
[отключают CsrfViewMiddleware (и их аналоги) в своих проектах -- только глупышки наподобие Александра Соловьёва -- https://bitbucket.org/piranha/byteflow/src/0109284f9a8d/sett... ]
2. SQL-Inj
а допустить SQL-Inj -- ТРУДНО и в случае Объектно-Реляционного-Отображения (ORM) и в случае DB-API
[зато очень ЛЕГКО допустить SQL-Inj -- в PHP при традиционном использовании там MySQL]
3. XSS
создание XSS -- опятьже -- довольно ТРУДНО в Django-подобных-шаблонизаторах, которые поумолчанию всё экранируют, кроме случаев где это не надо
############################## из этого всего делаем вывод ##############################
допускаемые ошибки -- сильно *зависят* от языка и библиотеки. а не только от опыта праграммирования
>[зато очень ЛЕГКО допустить SQL-Inj -- в PHPа где сложнее?
>при традиционном использовании там MySQL]а с MsSQL это будет сложнее сделать?
зыж
это применимо для ЛЮБОГО языка программирования. и СУБД соответсвенно тоже.ну а для того, кто даже прочитать доку (по-русски!!! не в каждом мсдн найдёшь :D) http://php.net/manual/ru/security.database.sql-injection.php не удосужился,... конечно пыхпых виноват.
странно что они в этом ещё сиквел-сервера не обвиняют. а то выдают понимаешь ли секюрную инфу всем подряд.
а сравненние фрэйворком с языками программирования... и не знаю как это назвать.
>>[зато очень ЛЕГКО допустить SQL-Inj -- в PHP
> а где сложнее?В java через JPA или любые языки работающие с SQL через связанные переменные.
Ха! Через.
А jdbc там ужО отменили?
Через <подставь_нужное> можно и в <подставь_любой_язык>.
А можно даже свои фильтры написать.Зыж
Когда в языках запретят прямой доступ к данным, тогда и придёт апокалепсис.
> Ха! Через.
> А jdbc там ужО отменили?
> Когда в языках запретят прямой доступ к данным, тогда и придёт апокалепсис.В каком то смысле jdbc уже отменили. в приложении ты можешь запросить работающий EntityManager, а можешь запросить JDBC коннект.
Потому несколько следствий:
1. с точки зрения приложения JPA не обертка поверх JDBC, поскольку приложение не имеет доступа к созданию JPA-инфраструктуры.
2. JPA может быть построен поверх иных нежели JDBC коннектов с системами хранения, в том числе и NoSQL.
3. поскольку все конфигуриврование инфраструктуры идет через архитектора проекта, а на боевых серверах через админа, то даже криворукие программеры не могут применить JDBC коннекты без разрешения архитектора. Коннекторов просто не создано в инфраструктуре.
>В каком то смысле jdbc уже отменили. в приложении ты можешь запросить работающий EntityManager, а можешь запросить JDBC коннект.не в каком-то, а в прямом смысле вы передёргиваете.
мягко говоря.
или возможно действительно не знаете о чём говорите (что гораздо хуже) - вот когда в жабе нельзя будет написать приложение, подверженное sql-injection, тогда и будете сравнивать технологии с языками программирования.
но надеюсь я до до такого идиотизма не доживу.
> вот когда в жабе нельзя будет написать приложение, подверженное ...причём тут "можно" или "нельзя"?
чащще всего ошибки допускаются -- в случаях когда их допустить ПРОЩЩЕ, чем НЕ допускать...
...а в случае когда-же ПРОЩЩЕ НЕ допускать ошибку, чем её допустить -- ошибки допускаются на порядок реже [если не сказать что не допускаются вообще].
выше указаны примеры библиотек/языков -- в которые постронны таким образом что ошибку (SQL-Injection, XSS, CSRF) там прощще НЕ допустить
почему я оперирую термином "библиотека/язык" (а не просто "библиотека") ??? потомучто библиотеки строятся вокруг языка, а не в сферическом вакууме
> причём тут "можно" или "нельзя"?Что ж. Объясню ещё раз.
Php — это язык. Как и java.
И там и там можно использовать различные технологии и техники.
Включая и те что приводят/не_приводят к sql-injection.
Упомянутый jpa — не язык, а технология.
Сравнивать язык и технологию более некомпетентно, чем тёплое и мягкое.
>> причём тут "можно" или "нельзя"?
> Что ж. Объясню ещё раз.
> Php — это язык. Как и java.
> И там и там можно использовать различные технологии и техники.
> Включая и те что приводят/не_приводят к sql-injection.
> Упомянутый jpa — не язык, а технология.
> Сравнивать язык и технологию более некомпетентно, чем тёплое и мягкое.хорошо.. чтобы Вы поняли мою мысль -- я спрошу вот так:
почему в PHP -- те техники которые приводят (провоцируют) к SQL-Inhection -- не удалят из языка? (в других же языках их удалили, или не допустили изначально)
you made my day. no, really!
присоединяюсь. :D
> почему в PHP -- те техники которые приводят (провоцируют) к SQL-Inhection -- не удалят из языка? (в других же языках их удалили, или не допустили изначально)не знаю, почему продолжаю отвечать...
нет таких языков. нет.
в той же жабе без jdbc не будет и jpa.
их отношения примерно такие же как https и tcp/ip.
и они также смешны, как если бы вы утверждали, что https лучше, чем tcp/ip.
зыж
к примеру оракл поддерживает аж 3-и (!!!) драйвера jdbc в актуальном состоянии.
а это единственный поддерживаемый путь получать данные на языке java из субд оракл.
мс также выпускает jdbc драйвера для своей mssql, включая и для linux.
запретить формировать запрос так, как удобно разработчику (не пользователю, повторяю!) НЕЛЬЗЯ.
а то получится "пчёлы против мёда".
>>В каком то смысле jdbc уже отменили. в приложении ты можешь запросить работающий EntityManager, а можешь запросить JDBC коннект.
> или возможно действительно не знаете о чём говорите (что гораздо хуже) -
> вот когда в жабе нельзя будет написать приложение, подверженное sql-injection, тогда
> и будете сравнивать технологии с языками программирования.Пожалуйста напиши мне пример JavaEE приложения на JPA с возможностью SQL-injection. )))
PS вообще проблема SQL-inject легко могла бы решиться если в СУБД запретить несвязанные переменные. ХЗ есть ли подобная возможность в современных СУБД.
Выше уже ответил.Зыж
И ещё потом удивляются отношения к жабистам, как к курице, которая не птица.
Ззыж
И да, напишиТЕ.
Соблюдайте хоть видимость вашего образования.
> PS вообще проблема SQL-inject легко могла бы решиться если в СУБД запретить
> несвязанные переменные.Это константы запретить?
В java уже запретили что-ли?
Справедливости ради, в jdbc никто не подставляет параметры в sql выражения путем конкатенации строк, для этого есть http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedSt..., исключающий возможность инъекции и улучшающий производительность, за счет того, что разбор выражения выполняется один раз.API, в котором для подстановки параметров в sql выражения предполагается использовать конкатенацию или другие средства работы со строками, — неимоверный дебилизм.
>Справедливости ради, в jdbc никто не подставляет параметры в sql выражения путем конкатенации строк,серьёзно? никто-никто? :D
пример (и не откуда-нибудь, а с IBM!!! :D)
http://publib.boulder.ibm.com/html/as400/v4r5/ic2979/info/ja...
...
ResultSet rs = select.executeQuery ("SELECT * FROM "
+ collectionName + dmd.getCatalogSeparator() + tableName);
зыж
согласно вашему пониманию справедливости утверждаю, что в пыхпыхе никто не пользуется конкатенацией при формировании запросов.
все исключительно пользуются переменными привязки, согласно документации
http://www.php.net/manual/en/pdo.prepared-statements.php
$stmt = $dbh->prepare("SELECT * FROM REGISTRY where name = ?");
if ($stmt->execute(array($_GET['name']))) {мwhile ($row = $stmt->fetch()) {print_r($row);}
В PHP prepared statements добавили позже, следуя примеру JDBC. И да, те, кто изначально испорчен общением с PHP, и в JDBC будут использовать конкатенацию.В примере IBM в запрос подставляетсе не значение колонки, а имя таблицы — его привязать нельзя. На практике имя таблицы редко получается непосредственно от пользователя (разве что в средствах администрирования), поэтому тут проблемы нет.
> В PHP prepared statements добавили позже, следуя примеру JDBC. И да, те, кто изначально испорчен общением с PHP, и в JDBC будут использовать конкатенацию.На практике наблюдаю ровно противоположенное — те кто и использовал php столкнулись и с инжекциями, и с методами их обойти.
А вот спорченные жабой даже не задумываются и верят что очередная жпа их спасёт.
И за примерами ходить далеко не надо — тут, на опеннете пишут, что в жабе нет меморилик, нет sql-injection и тд.
И пишут код соответсвенно.
Вы бы уж говорили за себя. Потрудитесь почитать следующее:
http://codeigniter.com/user_guide/libraries/input.html
Очень познавательно будет для Вас расширить кругозор и не тявкать впредь не удосужившись погуглить, как с этим XSS (ипрочими) эффективно борятьсяв толковых фреймворках.
в хоть программировали на этих языках, или это так, точка зрения жаба/дотнет-кодера? пардон, если я ошибаюсь.
Плевки жабистов и дотнетчиков в сторону Сей и Крестов на форумах - это не точка зрения, это нечто физиологическое.
> Плевки жабистов и дотнетчиков в сторону Сей и Крестов на форумах -
> это не точка зрения, это нечто физиологическое.Как будто они багов в том числе и ведущих к уязвимостям не делают :)
> Нормально так. Все ошибки показательныВсе программы имеют ошибки? Капитан, Вы?
Многое пишется на явах, шарпах, но когда в статье говорится о ядре линукса, к примеру, или о бд postgres, сама критика с/c++ становится не то, что неуместной, а какой то неадекватной.
> большие проекты на C,C++ неизбежно будут страдать от ошибок программиста отслеживать в ручную управлением памятью и пр.Что касается С++, то в 21-м веке уже нет никакой необходимости управлять памятью или любыми другими ресурсами вручную. Если кто-то всё еще считает, что в С++ управляют памятью руками, то он отстал от жизни лет на 10, а может и на 15.
>> большие проекты на C,C++ неизбежно будут страдать от ошибок программиста отслеживать в ручную управлением памятью и пр.
> Что касается С++, то в 21-м веке уже нет никакой необходимости управлять
> памятью или любыми другими ресурсами вручную. Если кто-то всё еще считает,
> что в С++ управляют памятью руками, то он отстал от жизни
> лет на 10, а может и на 15.печаль тут в том что некоторые не только считают, но ещё е УПРАВЛЯЮТ в C++ ресурсами вручную :-/ ...
С++ надо вообще прибить как не нужный балласт между С и более высшими языками.
и тут Остапа понесло... ;) просто уровень абстракции несколько другой, но не до такой же степени, чтоб из константной строки при сложении с объектом-переменной создавать объект. o_O
Вот я из-за принципа Ц++ не юзаю. Рядом со мной сидят ещё трое, вот они там х..ячат
интерфейсы на плюсах, у меня мозг вянет после их диалогов... И главное обсуждаются
не проблемы, скжем, узких мест тех или иных алгоритмов сортировки, а как какой объект
куда-то вынуть, член в класс, классы члена в объект, всё это в конструктор, а потом
деструктор, а почему не работает деструктор, а какого фига оно не delete если тама
авто деструктор, члены, классы, члены, классы,члены, классы,.... а-а-а-а-а-а...
> И главное обсуждаются не проблемы, скжем, узких мест тех или иных алгоритмов сортировкиНе знаю как где, но авторы С/С++ позаботились о том, чтобы прикладным программерам не нужно было обсуждать алгоритмы сортировки.
Для С есть функция qsort. Для С++ - stl::sort(). Можешь быть уверен, реализованы они через наилучший алгоритм.
наилучший?
Как насчёт почти-полностью отсортированных данных, где нужен radix,
или как насчёт большого объёма данных, где нужна комбинация radix/qsort с merge sort, т.к. qsort медленный если данные не в кеше процессора.Надо не быть уверенным в непогрешимости инструмента а знать слабости и уметь расширять.
т-с-с! как ты посмел сомневаться, неверный? stl и libc созданы не человеками, но спущены богами! понятно же, что там всё наилучшее. всегда. для всего.
Но там действительно наилучшие решения на данный момент времени. Всегда. Изобретать свой велосипед нет никакого смысла в этой области, даже для каких-то крайне специфичных задач.
Уважаемый, "наилучших" алгоритмов не существует. Для любого данного алгоритма есть случаи когда он оптимален и когда нет.
> Уважаемый, "наилучших" алгоритмов не существует. Для любого данного алгоритма есть случаи
> когда он оптимален и когда нет.он не поймёт. увы.
Раз уж вы завели ликбез-дуэт, допевайте куплет: и эта самая оптимальность алгоритма играет хоть сколько-нибудь значимую роль далеко не в любом случае. Преждевременная оптимизация и все такое.
Та же STL более чем оправдана практически везде, кроме реально узких мест. Речь, конечно, о грамотном ее применении.
ты что сказать-то хотел?
Что стремление к оптимальности алгоритмов должно чем-то оправдываться. Процессор давно перестал быть узким местом, и практической разницы между работой оптимального и неоптимального алгоритмов добиться все труднее. И тормоза уже чаще возникают не из-за применения медленных алгоритмов, а от архитектурной кривизны велосипедов, написанных перфекционистами, брезгующими стандартными библиотеками.
> Процессор давно перестал быть узким местома мужики до сих пор не знают… наверное, ты просто всем сообщить не успел пока.
p.s. я так понимаю из твоих слов — пофигу, что пузырёк, что heap? круто.
Сплошь и рядом - пофигу. До и после сортировки может происходить много чего интересного, да еще и не оптимизируемого, в отличие от. И внезапно оказывается, что все сэкономленное время процессор пинает балду в ожидании периферии.
Никто не спорит, что в проектах уровня PHP или PostgreSQL существуют места, где эта разница есть.
А вот в обычной программерской жизни - далеко не всегда. И испортить программу неудачным представлением данных куда легче, чем неудачным выбором алгоритмов.
вот что интересно: вроде бы и связно человек пишет, и вещи достаточно неглупые — а всё равно получается чушь не по теме. почему так…
По двум причинам. Во-первых, это все-таки холиварный срач, приходится соблюдать стиль.
Во-вторых, тема началась с того, что STL на практике обычно куда лучше велосипедов. Я, собственно, этой темы и придерживаюсь.
Тут много говорили о том, что язык мало что дает - им еще надо уметь пользоваться. Так вот, чтобы сделать лучше, чем в STL, нужно очень хорошо знать язык. Обычно лучше будет не выпендриваться и не тратить время столь высококлассного специалиста на столь ничтожную отдачу.
> Во-вторых, тема началась с того, что STL на практике обычно куда лучше
> велосипедов.не *куда лучше*, а *всегда лучше*. вот на что стойку сделали.
Тут логическая нестыковка: либо вы читаете оппоненту ликбез, либо предполагаете, что ему действительно придется иметь дело со случаями, когда STL не годится.
Это два очень разных оппонента получаются, как мне кажется ;)
Наилучший для общих случаев, которых 99%.
Да, исключительные условия, возможно, потребуют специальных алгоритмов, если производительность окажется неудовлетворительной, но это является скорее академической задачей, независящей от языка.
>Да, исключительные условия, возможно, потребуют специальных алгоритмов, если производительность окажется неудовлетворительной, но это является скорее академической задачей, независящей от языка.Я искренне рад за тебя, и даже завидую. Зафигачил qsort и радуешься.
ну какие-то мелочные они у тебя. ко мне коллеги обычно обращаются с просьбами расширить опциями интерфейс - не больше. я к ним - с такими же претензиями. что-то концептуальное - совещание делаем. но не дискутируем по каждой мелочи. у каждого есть строго своё поле действий. кто писал код, тот и получает тикеты. хотя, тот же проект можно переписать на сях, но много переделывать нужно будет. векторы, к примеру. не сильно хочется на realloc/malloc переходить и на связные списки. понимаю, что это фактически то же самое, только в обвеске разница. но тем не менее :) рубили бы с самого начала на сях - другое дело. а сейчас уже позно рыпаться.
>Вот я из-за принципа Ц++ не юзаюС такими принципами может и с линуксом завязать, где на сях много чё написано, да ник сменить?
Помарочка - на плюсах, а не сях
> что в С++ управляют памятью руками, то он отстал от жизни лет на 10, а может и на 15.В XXI веке нет никакой нужды в этих галимых велосипедах, самолетах и поездах! Ведь давно уже придуманы ракеты! А то что в магазин в соседнем закоулке так ездить не очень практично получается - ну извините...
> Нормально так. Все ошибки показательны для языков программирования C, C++ и являются
> их генетическими дефектами. Как вывод: большие проекты на C,C++ неизбежно будут
> страдать от ошибок программиста отслеживать в ручную управлением памятью и пр.н-да.
большая часть, а именно:
Разыменование NULL-указателя (Null Pointer Dereferences) 2,818
Неинициализированные переменные (Uninitialized Variables) 2,051
Повреждения памяти (Memory Corruptions) 1,551Ошибки присутствия прямой работы с памятью. И это в 2012 году =(((
И не говори, GC также жрет неуёмно память. в runtime выполняется куча всякой левой фигни. И это в 2012 году =(((
> И не говори, GC также жрет неуёмно память. в runtime выполняется куча
> всякой левой фигни. И это в 2012 году =(((Да. Тут выбор либо ошибки в коде или CPU работает за программиста. Машина должна думать, а человек работать. Только час работы машины несоизмеримо дешевле часа работы человека. Как следствие ВСЕ, что можно переложить на машину нужно переложить на нее.
Потому либо работает GC, либо за GC вынужден работать человек. Человек ошибается намного чаще. Потому либо код дешевле (поскольку меньше багов и меньше тестирования) либо код ДОРОЖЕ за счет большего количества багов и требования тестирования.
Никакой фантастики - java, как и C# прошли в лидеры поскольку код защищен от части проблем более низкоуровневых языков. Как только появится язык, который принципиально уберет часть багов из java и C# (к тому же будет простым в применении), так сразу он начнет захват энтерпрайза.
<Как только появится язык, который принципиально уберет часть багов из java и C# (к тому же <будет простым в применении), так сразу он начнет захват энтерпрайза.
Хочется верить, что так может быть, но до последнего времени все критичные к производительности программы делались на сях да плюсах притом с асмовскими вставками в критических случаях, ибо на языках вроде явы да шарпа - съедание памяти да падение скорости повышаются чуть ли не в геометрической прогрессии. Если все-же такой язык и возможен - это, наверное, потребует скорее аппаратного решения, а не просто синтаксиса и прочих особенностей языка, но пока такие решения проваливались.
Помарочка - сях да плюсах
>[оверквотинг удален]
>> C# (к тому же будет простым в применении), так сразу он
>> начнет захват энтерпрайза.
> Хочется верить, что так может быть, но до последнего времени все критичные
> к производительности программы делались на сях да плюсах притом с асмовскими
> вставками в критических случаях,
> ибо на языках вроде явы да шарпа
> - съедание памяти да падение скорости повышаются чуть ли не в
> геометрической прогрессии. Если все-же такой язык и возможен - это, наверное,
> потребует скорее аппаратного решения, а не просто синтаксиса и прочих особенностей
> языка, но пока такие решения проваливались.Начнем с начала, что в реал-тайме вообще выделение/освобождение не должны применяться. А в идеале запрещены. К этому высказыванию я вернусь позже.
Производительность бывает разная. Раньше я считал, что java не подходит для "критичных по времени" приложений типа VoIP. Фига два - сделаны сервера для VoIP на чистой java. Знаком с системой анализа трейдинговых данных (это которая выдает решения покупать/не покупать акции в течении микросекунд.
Есть целая подсистема для real-time программирования на java. В ней в real-time тредах вообще запрещено выделение памяти (как в любой максимально real-time среде). Хочешь RT - делаешь RT-thread и работая в рамках ограничений пишешь код. GC не мешает ибо для RT-тредов не актуален.
Так что на java можно делать разные приложения ;)))
ну вот — чего не хватишься, всё у них запрещают. а почему, собственно, надо запрещать? потому что некоторые путают RT и «хочу все ресурсы и чтобы никто не дёргал»? или потому, что не способны даже GC с прогнозируемым временем исполнения написать?вообще, не начинал бы ты про RT. не надо. а то у меня комплекс неполноценности будет от того, что я однажды вполне себе использовал для RT Scheme с вполне рабочим GC. и оно таки было RT. и даже работало без проблем. а оказывается, так нельзя…
> ну вот — чего не хватишься, всё у них запрещают. а почему,
> собственно, надо запрещать?Запрещать нужно для запрета совершать ошибки.
> или потому, что не способны
> даже GC с прогнозируемым временем исполнения написать?Даже на С++ освобождение памяти динамической структуры может занять не прогнозируемое время. Элемент может содержать другой, который содержит список ... и дальше до бесконечности. Потому либо заранее ограничивать типы объектов, следить чтобы другие типа не использовались в RT коде (что упирается в человеческий фактор) либо не применять динамическое выделение памяти вообще.
Второй подход позволяет уже в теории убрать часть проблем, что снимает проблему человеческого фактора. А это одна из основных задач развивающих программирование.
> вообще, не начинал бы ты про RT. не надо. а то у
> меня комплекс неполноценности будет от того, что я однажды вполне себе
> использовал для RT Scheme с вполне рабочим GC. и оно таки
> было RT. и даже работало без проблем. а оказывается, так нельзя…Я уже приводил примеры RT приложений на pure-java. Причем даже на базовом GC от HotSpot, а не на G1. Так что можно писать RT приложения с GC, но в массовом производстве грамотнее применять иные подходы.
> Даже на С++ освобождение памяти динамической структуры может занять не прогнозируемое время.с каких пор это костылище стало эталоном? O_O
> Элемент может содержать другой, который содержит список ... и дальше до
> бесконечности.каким образом это должно волновать инкрементальный GC с зональным аллокатором, например?
>> Элемент может содержать другой, который содержит список ... и дальше до
>> бесконечности.
> каким образом это должно волновать инкрементальный GC с зональным аллокатором, например?Я уверен, что вы умеете писать программы так, что в них не содержатся ошибки. Но большинство программистов не такие. Потому и GC делается для общего случая и языки стремятся защитить разработчика от наиболее частых ошибок.
PS вы спорите защищая С и С++ в которых найдены месторождения элементов кривой работы с памятью? Разыменование NULL-указателя (Null Pointer Dereferences), Неинициализированные переменные (Uninitialized Variables), Повреждения памяти (Memory Corruptions)?
> PS вы спорите защищая С и С++нет, я умиляюсь тому, как жабисты гордятся своими костылями.
p.s. как будто в жабе нет memory leaks. бугога.
> p.s. как будто в жабе нет memory leaks. бугога.мемори ликов - нет (пока сама JVM не течет, но и это давно отлажено). в сферических случаях могут быть созданы огромного размера List или Map, которые только наполняются данными, но данные не удаляются. да, память закончится. Только не от утечки (сиречь память выделена, но не может быть использована из приложения), а от через мерного потребления памяти логикой приложения.
На С/С++ можно и потерять память (она не доступна из кода ибо нет ни одного указателя) и пережрать память в логике.
Более высоко-уровневые языки лечат проблему потерянной памяти (memory leak), но пережор памяти в логике кода не подвластен. Хотя не факт что пережор вообще излечим машинными методами. )))
(задумчиво) совсем нет, ага. только вот пардон, заякореные данные, к которым программа никогда не обратится — это что? лично я это называю memory leak. и совсем не важно, доступен «якорь» или нет (вообще-то и в c/c++ всё доступно, ходи себе по структурам аллокатора да развлекайся на здоровье; так что даже с «недоступна из кода» ты ошибся: указатели есть, просто ты не знаешь, где их взять).я, кагбэ, намекаю, что GC не панацея. а иногда и вовсе overkill.
> я, кагбэ, намекаю, что GC не панацея. а иногда и вовсе overkill.А иногда и просто медвежья услуга. Тем более что дебилушки не умеют им нормально пользоваться и поэтому когда прога жрет эн гигз даже и не поймешь, толи она течет, толи это оно просто еще не сдулось. Поэтому типичная энтерпрайзятина на яве серваки ниже 16 ядер и 128Г оперативы за машины не считает.
> память закончится. Только не от утечки (сиречь память выделена, но не
> может быть использована из приложения), а от через мерного потребления памяти
> логикой приложения.Да как ни назови, если память так или иначе утекает, это утечки памяти. Вообще, при явном управлении памяти програмер по крайней мере в курсе что он делает. А в случае GC типовой code monkey вообще обычно не может оценить что и когда произойдет. Предсказуемость работы программы во втором случае - "о, вроде 1 раз не сглючило, пошли релизить!"
> Начнем с начала, что в реал-тайме вообще выделение/освобождение не должны применяться. А в идеале запрещены.мне в реалтайме нужно обрабатывать поступающие из очереди запросы. И как я это сделаю не выделяя/освобождая память, если я не знаю, сколько памяти потребуется для обработки запроса, пока его не заберу?
Если вам нужно часто просить/освобождать память относительно небольшими (в среднем много меньше страницы) кусками, есть кошерный выход -- вы самостоятельно пишете аллокатор в юзерспейсе, заточенный специально под ситуацию. Ускоряет обработку неиллюзорно. Проверено на системе, которая обрабатывает до 65536 очередей с запросами, требующими для обработки от нескольких байт до мегабайта.
>> Начнем с начала, что в реал-тайме вообще выделение/освобождение не должны применяться. А в идеале запрещены.
> мне в реалтайме нужно обрабатывать поступающие из очереди запросы. И как я
> это сделаю не выделяя/освобождая память, если я не знаю, сколько памяти
> потребуется для обработки запроса, пока его не заберу?Предварительное аллоцирование по максимально возможному размеру запроса. В RT все равно не будет мегабайтных XML-партянок, потому по ТЗ можно заранее предсказать размер и аллоцировать нужное количество.
PS Для soft real-time есть еще один вид тредов (помимо базовых и hard real-time).
> Никакой фантастики — java, как и C# прошли в лидеры поскольку…затачивались под стадо взаимозаменяемых обезьян. вот и весь секрет.
> Как только появится язык, который принципиально уберет часть багов из java
> и C# (к тому же будет простым в применении), так сразу он начнет захват
> энтерпрайза.нет. как только появится язык *ещё тупее*, чем жаба — так вот и начнёт. проблема в том, что особо тупее-то и некуда, если хочется язык хоть немного практически полезным сохранить.
а так — я тебе секрет расскажу: Smalltalk в применении прост. и gc там есть. и классы. и весьма навёрнутый отладчик с возможностью отлаживать *работающую* систему — без специальных хуков, сборок, запуском под «инструментальной средой» и так далее. а вот не захватывает он «ынтырпрайзы». потому что code monkeys cannot into Smalltalk.
товарищ Гослинг знал, что проектирует и для чего. «криэйторы, Вава, криэйторы.»
Да-да, раньше вот были знатоки и профессионалы: лошадь подкуешь, запряжешь, сидишь на ней правильно, потом распрягать, чистить, корм тот же правильно подобрать нужно... А сейчас? За руль садятся, зажигание включают - и поехали. Обезьяны, чего с них возьмешь...
А сейчас в авариях погибают больше чем во время боевых действий. Обезьяны, чего с них возьмешь...
>…затачивались под стадо взаимозаменяемых обезьян. вот и весь секрет.Как впрочем и с++. Куда то толпу симула погромистов надо было девать.нет. как только >появится язык *ещё тупее*, чем жаба — так вот и начнёт. проблема в том, что особо тупее-то и некуда, если хочется язык хоть немного практически полезным сохранить.
Я бы не назвал java тупым. Излишне много словным - да, медленно развивающимся - да. Но не тупым.
>потому что code monkeys cannot into SmalltalkВообще то, основной причиной по которой Smalltalk, проиграл java было то что он был на тот момент платным. А вообще есть хорошее выступления "What Killed Smalltalk" от дяди Боба:
http://www.youtube.com/watch?v=YX3iRjKj7C0
> Я бы не назвал java тупым. Излишне много словным — да, медленно
> развивающимся — да. Но не тупым.увы, он реально тупой. да ещё и испорченый попыткой запихать туда концепции, которые изначально там не планировались и не были нужны. к тому же он совершенно неконсистентный (ага, мой любимый пример с int и Integer). я понимаю, зачем так было сделано, но костылями оно от этого быть не перестаёт.
> Вообще то, основной причиной по которой Smalltalk, проиграл java было то что
> он был на тот момент платным.и по этой тоже, конечно. но не только по этой.
p.s. я не говорю, что цпп-обезьянки чем-то сильно лучше. увы-увы.
> увы, он реально тупой. да ещё и испорченый попыткой запихать туда концепции,
> которые изначально там не планировались и не были нужны. к тому
> же он совершенно неконсистентный (ага, мой любимый пример с int и
> Integer). я понимаю, зачем так было сделано, но костылями оно от
> этого быть не перестаёт.Будь последователен - расскажи в чем неконсистентность наличия примитивного и объектного типов для одного типа данных?
> для одного типа данных?ты сам уже всё сказал. если до сих пор не очевидно — медицина бессильна.
p.s. помимо прочего, это нарушает базовый принцип жабы «всё на свете объект». почему, собственно, Integer — объект, а int — нет, но при этом они оба представляют целое число?
и вот вся жаба из таких костылей сделана. поэтому надо кропотливо запоминать всяческие исключения, вместо того, чтобы понять базовый принцип и дальше применять обычную логику.
>> для одного типа данных?
> p.s. помимо прочего, это нарушает базовый принцип жабы «всё на свете объект».
> почему, собственно, Integer — объект, а int — нет, но при
> этом они оба представляют целое число?Да, есть косяк. Появился в лохматом году из за того, что на объектах работать слишком накладно (кроме затрат на данные еще траты на ссылку и сам объект). Потому сделали int для примитивов и Integer для объектных. Дальше ловушка обратной совместимости. Из-за этой х-ни даже авто-боксинг придумали, что есть костыль по сути.
Стоит взглянуть на новые разработки типа Ceylon или Kotlin. Вроде как там однозначные типы - все объект. При этом уже компилятор/среда отвечают за то чем это будет представлено объектом или примитивом.
я же сказал: я понимаю, зачем так было сделано. я не понимаю, почему жабисты при этом считают жабу нормальным языком — даже тогда компилятор мог спокойно разрулить большинство случаев. тю, даже мой простенький компилятор смолтолка (на смолтолке же и сделаный, чтобы уж совсем сравнивать) вполне приемлемо разруливает и работу с числами, и инлайнинг аксессоров.к чему я это? к тому, что в языке для обезьян пофигу консистентность, всё равно обезьянам это неинтересно, они пишут путём копипасты.
p.s. случай смолтолка, кстати, сложнее ввиду того, что метаклассы можно наращивать уже после того, как программа запущена. пришлось читерить ещё и в VM. а у жабы всё известно наперёд (не будем вдаваться в мегакостыли с рантаймовым патчингом сейчас).
> я же сказал: я понимаю, зачем так было сделано. я не понимаю,
> почему жабисты при этом считают жабу нормальным языком — даже тогда
> компилятор мог спокойно разрулить большинство случаев. тю, даже мой простенький компилятор
> смолтолка (на смолтолке же и сделаный, чтобы уж совсем сравнивать) вполне
> приемлемо разруливает и работу с числами, и инлайнинг аксессоров.Ок. Это был маркетинговый ход для привлечения С++ ников, которых много и для которых примитивы маст-би.
Увы любой язык с полной обратной совместимостью на всю жизнь превратится в набор костылей через 15 лет. За это время появляются новые удачные концепции, а внедрить их изменив синтаксис уже нельзя.
PS еще один камень в огород java это дженерики. довольно кривое поделье, которое еще и auto-boxing вовсю использует.
PPS много такого рода вещей исправлено в целон и котлин. Посмотрим насколько они будут удачны по итогу ;)
там для начала неплохо было бы саму JVM починить, с её боксингом всего и вся. а также приделать туда нормальные замыкания и TCO. концепциям сто лет в обед, а без костылей никак. ужас.
> там для начала неплохо было бы саму JVM починить, с её боксингом
> всего и вся. а также приделать туда нормальные замыкания и TCO.
> концепциям сто лет в обед, а без костылей никак. ужас.Вы наверное удивитесь но замыкания в жаве внезапно! есть.
> Вы наверное удивитесь но замыкания в жаве внезапно! есть.я просто буду улыбаться, глядя на очередной костыль, про который жабисты сначала кричали «не надо», а потом его мегакриво реализовали — и жабисты решили, что они теперь тоже «как взрослые».
TCO тоже реализуется при помощи системы костылей, и что?
> там для начала неплохо было бы саму JVM починить, с её боксингом
> всего и вся. а также приделать туда нормальные замыкания и TCO.
> концепциям сто лет в обед, а без костылей никак. ужас.боксинг это фишка компилятора. синтаксичекий сахарок.
замыкания в прочем тоже сахар.
боксинг — это фишка VM. которая (VM) не позволяет передавать указатели/ссылки на элементарные типы. равно как и closures — фишка VM, потому что надо поддерживать обращение к вышележащим фреймам и их копирование.не спорь, пожалуйста — вряд ли ты занимался написанием VM. я — занимаюсь, лет уж… в общем, не цифрой выражается.
> а так — я тебе секрет расскажу: Smalltalk в применении прост.
> и весьма навёрнутый отладчик с возможностью
> отлаживать *работающую* систему — без специальных хуков, сборок, запуском под «инструментальной средой»Наверное про отладчик нужно писать для заманивания С или С++. Но явно не для java-истов у которых это out-of-box. =)))
Хочешь отлаживать работающую систему - да пожалуйста. Хоть через SSH прокинь, хоть еще как подцепись ;)))
у жабистов. отладка. оборжака. ребятки, когда у вас будет отладчик хотя бы в половину мощности и удобства смолтолкового — вы будете получать мультиоргазмы и смотреть на всех других как на дождевых червяков.я понимаю, что ты со смолтолк-системами не работал, поэтому даже не представляешь, что это такое и почему остальные нервно курят в сторонке. а ты попробуй. только не на уровне «яничегонепонялзначитфигня».
p.s. ещё один повод у меня ненавидеть жабу — вполне личный: сантехники купили команду, разрабатывавшую Strongtalk. попробуй без википедии угадать, для чего.
> у жабистов. отладка. оборжака. ребятки, когда у вас будет отладчик хотя бы
> в половину мощности и удобства смолтолкового — вы будете получать мультиоргазмы
> и смотреть на всех других как на дождевых червяков.из того, что увидел на вики-учебнике про отладчик для смаллтока и что не присутствует в java так это удобная разработка кода сразу в отладчике. Динамическая подгрузка классов в момент отладки - вещь работающая, хотя лично я ей редко пользуюсь )))
привык сначала писать код, потом отлаживать его если есть такая необходимость ;)
PS увы web-морду не всегда просто отлаживать даже в идеальных отладчиках
не надо читать вики-учебники. *особенно* по смолтолку. пока ты с этой системой ближко не подружишься — особого представления о ней никакие учебники и статьи не дадут. собственно, «отладчик» в смолтолке — инструмент для *разработки*, а не для просто *отладки*.уеб на St тоже вполне можно, кстати. и инструменты для отладки там тоже неплохие. я, впрочем, в этом плане мимокрокодил, глубоко не занимался.
>> Никакой фантастики — java, как и C# прошли в лидеры поскольку
> …затачивались под стадо взаимозаменяемых обезьян. вот и весь секрет.Капитан как обычно суров но справедлив :)
> Машина должна думать, а человек работать. Только час работы машины несоизмеримо
> дешевле часа работы человека. Как следствие ВСЕ, что можно переложить на
> машину нужно переложить на нее.Поэтому жабисты пытаются переложить на нее даже думание. Так, чисто глядя на поделки от таких как вы...
неа, зря ты: этот, вроде, вполне адекватный.
>> "будут страдать от ошибок программиста отслеживать в ручную управлением памятью"Является ли вышеприведенный текст "генетическим дефектом" русского языка?
Сегодня анализирует, завтра сама будет писать код. Не далеко до кнопки "Зделать зашибись". Так и до восстания машин докатится можно :(.
Ну, на компьютере давно есть кнопка "проверить орфографию" - кто же ей пользуется?
Три предложения - три ошибки. Зато машины не восстанут.
> дереве Staging и сетевом стеке уровень качества составляет 0.97, файловых системах 0.65, драйверах 0.61Посмотреть так вообще не понятно как оно умудряется работать, однако-же работает.
так и работает... то тут отвалится, то там
> команда разработчиков BRL-CAD устранила более 1600 дефектов в течение 5 днейВот это производительность труда! Они устраняли 40 дефектов в час! Или там просто штат очень большой?
Инфа непонятно откуда, гугл по "brl cad covernity" почти ничего не находит.
Coverity
Точно, туплю. Ну по крайней мере в англ. варианте так же:http://blog.coverity.com/uncategorized/coverity-releases-the.../
> Вот это производительность труда! Они устраняли 40 дефектов в час!И что, ты не запатчишь 40 кривых использований указателей за час например? Ну хотя если ты проприетарщик, понимаю, кто ж будет с рвением работать на дяденьку :)
> И что, ты не запатчишь 40 кривых использований указателей за час например?Ну, некоторые люди не просто перед каждым обращением указателю пишут "if (!p) return -1" (как это, вероятно, делаете вы) а изучают код и выясняют, почему же указатель оказался нулевым хотя не должен, и исправляют ошибку там, где она возникла, а не там, где проявилась. За полторы минуты этого не сделать.
И, да, я думаю, что имеются ввиду не 40 одинаковых строк в одной функции, а 40 указателей, разбросанных по всему проекту.
особенно интересно, как это выяснит система анализа, у которой вообще мозгов нет, только набор правил. я так сильно подозреваю, что починили десяток реальных ошибок и вставили кучу ненужных проверок, чтобы эта дура заткнулась уже и не нервировала.
"Мозги" такие же, как у человека -- находит находит подобие в заданной базе образцов.
нененене, господа модераторы. тут нам только что не напрягаясь решили основную проблему AI, а вы сообщения удаляете. ведь, оказывается, чтобы сделать эмулятор мозга — достаточно уметь находить подобие в базе образцов!
Да. Но не только. Нужно ещё эту базу образцов составить, т.е. "научить". Сколько там ребёнка ложку учат держать, а читать-писать? Будет ли экономически выгодной система на обучение которой уйдут десятки лет? Сделать "эмулятор мозга" (т.е. саморазвивающуюся адаптивную систему) трудно не логически, для этого вся математика есть, а чисто физически сложно добиться такой плотности связей и такой чувствительности, а значит способности к обучению.
> Ну, некоторые люди не просто перед каждым обращением указателю пишут "if (!p)
> return -1" (как это, вероятно, делаете вы)Не, ну что это за жирный троллинг? Вам не кажется что потоньше троллить надо?!
Возможно, ряд ошибок решался примитивной автозаменой - никто же не сказал, что ошибки были разными.
> Возможно, ряд ошибок решался примитивной автозаменой - никто же не сказал, что ошибки были разными.Добавьте к этому, что одно конкретное "плохое" место в коде может "выдавать" десяток ошибок (да еще и совершенно разнородных), так что переписав один кусок (возможно даже небольшой) удается избавиться от пары десятков ошибок разом.
Ну, статический анализатор и должен показывать как раз это место, а не те места, где оно используется. Разве что "это место" - шаблон.
>> команда разработчиков BRL-CAD устранила более 1600 дефектов в течение 5 дней
> Вот это производительность труда! Они устраняли 40 дефектов в час! Или там
> просто штат очень большой?Не, там ашипки типа
while (1) {
for ( i = 0; i > 0; i++);
if ( i = NULL );
printf(%d, 3.15159265);
else
goto exit();
}Уже 10 штук :)
Третье место — неинициализированные переменные. Как оно мимо gcc проходит? Или на выхлоп никто не смотрит, Werror не использует?
Видел ли ты что мимо IAR проходит? Там вообще такое ощущение что разработчики компилятора наркоманы и стандарт Си на косяки перевели. У меня теперь в практику вошло, весь код пришедший с IAR прогонять через GCC и Clang'овский статический анализатор. Clang кстати тоже многие интересные моменты замечает, что GCC пропускает.
> У меня теперь в практику вошло, весь код пришедший с IAR прогонять через
> GCC и Clang'овский статический анализатор. Clang кстати тоже многие интересные моменты
> замечает, что GCC пропускает.А как вам это удается, если не секрет? Я давненько не имел дел с IAR'овскими компиляторами, но раньше, помню, натравить что-то, кроме IAR, на проект сделанный конкретно под IAR было весьма проблематично в силу огромного числа платформо-специфичных и сильно-iar-специфичных конструкций (а без них iar выдавал такое, что без слез не взглянешь). Любая утилита и/или компилятор спотыкались и отваливались на таких штуках и без суровой правки исходников их нельзя было использовать.
> А как вам это удается, если не секрет?Сейчас там в IAR в основном все специфичные вещи запиханы в #pragma, которые GCC тупо игнорирует. Ну или мне пока очень везет=) Мне обычно и не надо, чтобы код с IAR собрался достаточно на warning и error поглядеть. А так да, приходится портировать. Просто весело когда кроме специфичных для компилятора #pragma или ещё чего вылезают вещи которые не совместимы с жизнью и IAR это лихо проглатывает.
> Видел ли ты что мимо IAR проходит? Там вообще такое ощущение что
> разработчики компилятора наркоманы и стандарт Си на косяки перевели.По моему скромному опыту, абсолютный рекордсмен и чемпион в этом сомнительном деле это TI CodeComposer Studio. Включить его в strict-режим невозможно - он прекращает компиляцию найдя более определенного количества ошибок (точно не помню сколько, но много). Ирония в том, что при этом он так и не доходит до ваших файлов - эта тьма ошибок (для strict-режима) уже в их собственных файлах.
Если не включать strict-режим, то он спокойно позволяет использовать, к примеру, функции без прототипа, а что он при этом реально вызывает и как передает параметры - загадка. Самое плохое, что он год будет все компилировать правильно, а потом, когда ты будешь править какие-нибудь незначащие строчки совершенно в другом месте в этой части получишь "биг-бада-бум" с вероятностью 50%. А хватило бы одного warning.
> По моему скромному опыту, абсолютный рекордсмен и чемпион в этом сомнительном деле
> это TI CodeComposer Studio.Я уже давно стал полным сторонником того, что проприетарные средства разработки зло полнейшее. Они вечно недопилены и кривы, особенно от производителей чипов. Тот же IAR, не считая компилятора (а он все-таки генерирует достаточно быстрый код, и библиотека Си компактна в отличии от того же newlib), но IDE, как с таким позором можно вообще в 21 веке появляться.
Мне повезло, моя контора не ограничивает средства разработки, поэтому использую самосборный toolchain на GCC и радуюсь.
А вообще это просто беда разработки встраеваемых систем, с одной стороны кривые поделки от производителей чипов и т.д. с другой такие же криворукие разработчики. Приходится иметь дело с недавними выпускниками наших вузов, берут их разрабатывать встроенное ПО. И они могут разбираться во всем, в схемотехнике, физике, но только не в программировании и даже интереса к нему не испытывают. Или наоборот наберут бывших явистов для которых элементарные понятия цифровой схемотехнки и электроники или беззнаковые типы и ограничение в 1Кб памяти - rocket science. Зато все как один в резюме указывают, что знают Си в совершенстве. Они видимо забывают, что знание убогого синтаксиса (хотя в живую встречал только двух человек которые читали стандарт С99) это только 10%, остальное - это знания и умения на этом убожестве прменять современные методики, алгоритмы и сопутствующие инструменты.
Зато пионеры горлопанят: "На Си нельзя писать большие проекты!!!" Это оттого, что их знания Си == 0. А вот зная Си + алгоритмы + различные парадигмы и методики программирования + подходящие средства разработки и умея это все применять, оказывается, что можно запилить проекты масштаба Linux и *BSD.
> Или наоборот наберут бывших явистов для которых элементарные понятия
> цифровой схемотехнки и электроники или беззнаковые типы и ограничение в 1Кб
> памяти - rocket science.Странные джависты, что джаву на С или С++ меняют. Возвожно как джависты не смогли адекватно работать, вот решили что С легче будет. Наивные =)))
PS хорошо отношусь к С и С++ разработчикам, но знаю что это другое множество задач ;)
> Мне повезло, моя контора не ограничивает средства разработки, поэтому использую самосборный toolchain на GCC и радуюсь.У меня, в этом смысле, аналогично. С некоторыми (а может и всеми) "сигнальниками" от Texas Instruments беда как раз в том, что альтернатив практически нет.
Analog Devices в этом смысле поступил гораздо лучше. Под многие семейства есть свободные toolchain и gcc, причем, судя по всему, исходно с некоторой поддержкой самих Analog Devices. Их собственные проприетарные компиляторы по опциям и "нестандартностям" более или менее похожи на gcc (даже в официальной документации к ним есть как минимум один раздел, посвященный сходствам и различиям с gcc).По поводу "молодых" - ситуация полностью аналогичная. Либо "профильные" ребята, но с программированием туго, либо "программисты", но настолько "объектно-ориентированные" и/или далекие от "железа", что нужны годы, чтоб из оставшихся вышел толк в нашем деле.
> По поводу «молодых» — ситуация полностью аналогичная. Либо «профильные» ребята, но с
> программированием туго, либо «программисты», но настолько «объектно-ориентированные»
> и/или далекие от «железа», что нужны годы, чтоб из оставшихся вышел
> толк в нашем деле.если бы только у вас так… проблема с нормальными сотрудниками. «— Летать не умеют, стрелять — тоже пока не умеют. Но — орлы!» то есть, денег хотят как орлы, и чтобы при этом их отходы жизнедеятельности считались полезной работой.
> это TI CodeComposer Studio. Включить его в strict-режим невозможно - он
> прекращает компиляцию найдя более определенного количества ошибок (точно не помню сколько,
> но много). Ирония в том, что при этом он так и
> не доходит до ваших файлов - эта тьма ошибок (для strict-режима)
> уже в их собственных файлах.Что ж ты от проприетарщиков то хотел, дяденька?
> Третье место — неинициализированные переменные. Как оно мимо gcc проходит? Или на
> выхлоп никто не смотрит, Werror не использует?
#include <stdio.h>
#include <string.h>const char *TEXT = "123456789";
int main()
{
char a;if (strlen(TEXT) > 20)
a = 'A';
if (strlen(TEXT) < 10)
printf("%d\n", a);return 0;
}$ gcc -W -Wall -Wextra -Werror -Wunused -Wuninitialized test.c
Молчит тварь :)
а с чего бы ему вякать, если неинициализированные глобальные статики попадают в BSS, которая по-умолчанию инициализируется нулями? перемести 'a' в main() и убери static — сразу заорёт.ты как первый раз замужем, честное слово.
p.s. опа, успел код поменять. забавно: a всегда инициализировано, причём значением из первого условия — если собирать с -O2. а если с -O0 — то там как и полагается бредятина. выверты gcc…
и да: молчит, зараза.
> перемести 'a' в main() и убери static — сразу заорёт.А может сразу инициализировать, хрен ли мучатся?!
Есть пример. Рабочий! Глючный! Умнож такую багу
на десяки тыщь строк, и ищи её там...
а ты тоже сразу отвечать не спеши, у меня волшебная кнопка редактора работает.
> а ты тоже сразу отвечать не спеши, у меня волшебная кнопка редактора
> работает.Соревнуетесь кто кого техничнее поднае... редактированием? :)
p.s. в любом случае за такой код надо тестикулы отрывать.
> p.s. в любом случае за такой код надо тестикулы отрывать.А в таком примере, переменная "a" может уползти далеко,
за 3-4 функции, через 5 файлов,... а если это библиотека,
которую использует другая библиотека, так ваще жо..а.
just don't do that. есть же хорошая практика: изначально присваивать переменной чушь и assert'ить. ну, и assert'ить на предмет соблюдения контрактов, конечно. «и много-много макросов детишкам принесла…»
> just don't do that. есть же хорошая практика: изначально присваивать переменной чушь
> и assert'ить. ну, и assert'ить на предмет соблюдения контрактов, конечно. «и
> много-много макросов детишкам принесла…»В ядре почти все свободные переменные неинициализируются.
Свободные, в смысле те, которые могут не использоваться.
Там каждый грамм на счету.
> а с чего бы ему вякать, если неинициализированные глобальные статики попадают в
> BSS, которая по-умолчанию инициализируется нулями? перемести 'a' в main() и убери
> static — сразу заорёт.
> ты как первый раз замужем, честное слово.
> p.s. опа, успел код поменять. забавно: a всегда инициализировано, причём значением из
> первого условия — если собирать с -O2. а если с -O0
> — то там как и полагается бредятина. выверты gcc…
> и да: молчит, зараза.
char *a;if (strlen(TEXT) > 20)
a = "A";
if (strlen(TEXT) < 10)
printf("%d\n", ++a);А вот так SEGFALT словим
Тогда или ++(*a), или %p и отсутствие сегфолта, не?
Во втором случае оно еще и ругается уже.
> забавно: a всегда инициализировано, причём значением из первого условия:)
> Третье место — неинициализированные переменные. Как оно мимо gcc проходит? Или на
> выхлоп никто не смотрит, Werror не использует?Все просто - не инициализированные переменные активно используются.
Есть специальная техника - туннелирование.
Позволяет передавать значения переменных в функцию без дополнительных затрат времени.
Выглядит это вот так:
#include <stdio.h>
void f1(){
int a = 100;
a++;
}
void f2(){
int b; /*!*/
printf("Sure 101 = %d",b);
}
int main(){
f1();
f2();
}
Очень активно используется в ядре линукс. Также почти все звуковые драйверы написаны подобным образом, но это скорее по историческим обстоятельствам.Метод работать то работает, только надежности не прибавляет.
Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось, -Wno-uninitialized например только в одном месте, не звук.
Кому нравятся ругань компилятора?
Правильно - никому.
Так что починим?
Правильно - нет.
Костылик вот наш ответ.
>>linux-3.3-rc5
/*
* A trick to suppress uninitialized variable warning without generating any
* code
*/
#define uninitialized_var(x) x = x
Ну ты понял.
Кстати ответ тем кто считает, что компилятор нам спасет от всех напастей.
и что это должно продемонстрировать? что компилятор неидеален, и иногда его ворнинги надо насильно затыкать? Кэп, мы в курсе. а просили мы продемонстрировать то, что ты назвал «тунелинг» и на голубом глазу утверждаешь, что в ядре оно «очень активно используется». поскольку ты так уверен — у тебя не должно быть затруднений с приведением хотя бы пары десятков мест, где это используется (хотя для «активно» надо бы сотни как минимум, да уж ладно…)
Прикольно. Но еще бы передачу между функциями увидеть.Хотя не понял, как это работает. Если использовать для глобальной переменной, то gcc выдает ошибку "initializer element is not constant". А для автоматической переменной почему не так? Компилит молча с "gcc -O0 -g -Wall -Wextra -pedantic --std=c90".
clang тоже молча собирает (с дефолтными опциями). С --analyze отлавливает.
> Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось,Ну вот напрямер http://lxr.linux.no/#linux+v3.2.7/drivers/xen/xen-selfballoo...
На 151-ой строке объявляют и не инициализируют cur_frontswap_pages,
на 155-ой это неясное значение присваивают другой переменной.
на 158-ой идёт сравнение, уже инициализированной, cur_frontswap_pages с
неясным значением у last_frontswap_pages.Тут и ёжику понятно, что эти две переменные используются
как проверка работы функции frontswap_curr_pages().
То есть, это присваивание однозначно определяет то,
что эти две переменные меж собой равны, даже не инициализируемые вручную.Но факт присваивания неинициализированной переменно налицо.
Вот Coverity, за подобный такому, шухер, и получает бабло от АНБ,
заказы от корпоративщиков, и орёт на каждом заборе, что они находят баги. :)
static void frontswap_selfshrink(void)
{
static unsigned long cur_frontswap_pages;
static unsigned long last_frontswap_pages;
static unsigned long tgt_frontswap_pages;last_frontswap_pages = cur_frontswap_pages;
cur_frontswap_pages = frontswap_curr_pages();
if (!cur_frontswap_pages ||
(cur_frontswap_pages > last_frontswap_pages)) {
frontswap_inertia_counter = frontswap_inertia;
return;
}
...
>> Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось,
> Ну вот напрямер http://lxr.linux.no/#linux+v3.2.7/drivers/xen/xen-selfballoo...
> На 151-ой строке объявляют и не инициализируют cur_frontswap_pages,
> static unsigned long cur_frontswap_pages;эй, а разве static переменные внутри функции не в ноль инициализируютя по умолчанию ?
> эй, а разве static переменные внутри функции не в ноль
> инициализируютя по умолчанию ?а вот кстати не помню. ау, у кого там стандарт под рукой?
А кстати да. То есть работать должно нормально, хоть стиль и.. хромает.If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.
>>> Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось,
>> Ну вот напрямер http://lxr.linux.no/#linux+v3.2.7/drivers/xen/xen-selfballoo...
>> На 151-ой строке объявляют и не инициализируют cur_frontswap_pages,
>> static unsigned long cur_frontswap_pages;
> эй, а разве static переменные внутри функции не в ноль
> инициализируютя по умолчанию ?Практически везде в 0, но это скорее костыль чем фича. :)
человек имел в виду совсем другое. он утверждает, что в ядре активно используется хак с неявной передачей локальных переменных через стек. вот мы хотим видеть доказательства сего утверждения. твой пример — он совсем из другой оперы, тут и стек-то не задействован.
на самом деле даже средней тупости оптимизатор понаделает тут мегапроблем. что, кстати, было известно давно, чуть ли не с момента появления оптимизирующих компиляторов.кстати, а где в пингвинусе это активно используют? не трололо для, просто интересно. самому рыть исходники долго и лениво, а ты, судя по всему, уже в курсе.
> Позволяет передавать значения переменных в функцию без дополнительных затрат времени.
> ...
> Очень активно используется в ядре линукс. ...если это используется хотябы гдето [я имею ввиду серъёзные проекты, а не на домашней странице Васи Пупкина] -- то я очередной раз очень разочаруюсь в жизни :-(
> если это используется хотябы гдетораньше использовалось. тю, сам использовал ещё во времена DOS — даже с разрешёнными прерываниями.
> Очень активно используется в ядре линукс.Ага, щаз, сто тыщь раз...
gcc -fipa-pure-const test.c
./a.out
101=0-fipa-pure-const входит во флаг -O, а линуховый дефолтный -02
Так что, слово "активно" совсем не уместно.
т-с-с-с. ну что ты всё ломаешь? щаз обидишь его, и он не скажет, какие именно участки ядра надо переделать. а я хотел потом втихаря патчей заслать и выпендриться, сколько багов починил!
> Все просто - не инициализированные переменные активно используются.
> Есть специальная техника - туннелирование.
> Позволяет передавать значения переменных в функцию без дополнительных затрат времени.Это должно работать очень ненадёжно.
Gcc любит оптимизацию работы со стеком следующим образом: возврат позиции SP (ESP, RSP - неважно) после каждой функции не делается, а делается только в конце. При нескольких последовательных вызовах позиция SP будет постепенно уползать влево. Это частично отключается в случае вызовов внутри цикла (SP на входе в цикл должен иметь всегда одно и то же значение), но при линейных вызовах позволяет экономить операции.
При такой оптимизации адреса для f1.a и f2.h будут разными, и передача данных не случится.
> Очень активно используется в ядре линукс. Также почти все звуковые драйверы написаны
> подобным образом, но это скорее по историческим обстоятельствам.
> Метод работать то работает, только надежности не прибавляет.Ну теперь я не удивляюсь тому, как в Linux относятся к звуку.
> Ну теперь я не удивляюсь тому, как в Linux относятся к звуку.нашёл кому верить. видишь же: на просьбу показать конкретный код чувак слился и не отсвечивает.
Перечитал первый абзац 5 раз. Так и не понял, как из 0,45 и 0,64 можно получить в среднем 1.
> Перечитал первый абзац 5 раз. Так и не понял, как из 0,45
> и 0,64 можно получить в среднем 1.читать надо учится ...
первые два числа взяты в результате тестирования КОНКРЕТНЫХ ПРОДУКТОВ
последнее - ПО ОТРАСЛИ В ЦЕЛОВ
А запросто. 0.45 и 0.64 -- это усреднение по проектам, а 1.0 -- по всем строкам всех проектов (сказывается вклад низкокачественных проектов с большим числом строк).
Где пометка «На правах рекламы»?
> Где пометка «На правах рекламы»?Coverity абсолютно бесплатно тестирует все проекты под открытыми лицензиями, нужно только заявку написать.
Мы без них потестируем. Пущай код отдают.
А то блин всё проверят, а самое вкусное покажут только ФБР, АНБ и ЦРУ.
> Например, команда разработчиков BRL-CAD устранила более 1600 дефектов в течение 5 днейВот я хотел услышать о команде разработчиков ядра линукс :) , но об этом дипломатично промолчали. Значит плохи дела... :))))
Зато у проприетастов всё хорошо.
Это хотел сказать?
> Вот я хотел услышать о команде разработчиков ядра линуксВы хотели услышать, что в ядре Линукс до сих пор была россыпь ошибок, на устранение каждой из которых в среднем требуется несколько секунд?
Так вот, таких ошибок там не нашлось. Что вас в этом расстраивает?
"Не нашлось" это синоним "нет вообще"? Тогда почему ежемесячно обновляются ядра, не подскажешь? Или все-таки будем реалистами?
Еще лучше, еще быстрее!!
Ну, так и будьте реалистом, а не пустословом.
Устранение ошибок отнюдь не означает, что они были такими тривиальными, что их может обнаружить даже компьютер (речь об этом).
> Тогда почему ежемесячно обновляются ядра, не подскажешь?ChangeLog знает.
Пока писал ответ, тред удалили.> То есть, Вы таки обвиняете авторов вышеуказанных ядра PHP и Postgre в непрофессионализме?
Фактически, да.
Объясняю подробнее: не все комиттеры в эти проекты обладают нужным уровнем
профессионализма в использовании С/С++. Они могут быть выдающимися учеными (или любителями) в области компиляторов и/или структур данных, и др., но им явно не хватает опыта в использовании языков, на которых они реализуют свои идеи.
Об этом и свидетельствует статистика Coverity.Может возникнуть вопрос, а как же приобрести этот необходимый опыт, кроме как программируя? - правильно, никак. Но самураям тоже не сразу давали в руки настоящий меч. Нужно было какое-то время потренироваться на деревянных - лучше не подпускать студентов (и к ним приравненных) к таким жизненно важным проектам как ядро, Postgre.
И как тут не вспомнить GSoC...
А PHP вообще сначала расшифровывался как Personal Home Page.
Положим, студентов никто и не допускает ни до ядра и до СУБД. Там есть специальные люди, которые решают, внести патч или нет. И все патчи проходят контроль - хотя бы на отсутствие закладок. Нет, раз ни авторы, ни те, кто в продукт включал код, не нашли ошибок, значит они крайне неочевидны.
Проблема гораздо глубже.
С появился, как ответ на определенную ситуацию, в точности также, как позднее и С++. Все новые и новые языки придумывают не просто так: многих системных архитекторов уже не устраивают возможности этих языков. Но из-за огромной массы уже написанного и отлаженного кода перейти на D или что-то иное тоже невозможно...
Я думаю, что разработчикам С/С++ компиляторов нужно делать больший упор на анализ, чтобы такие ошибки можно было отлавливать если не прямо в IDE, то хотя бы на этапе компиляции.
> Нет, раз ни авторы, ни те, кто в продукт включал код, не нашли ошибок, значит они крайне неочевидны.По собственному опыту могу сказать, что в большинстве случаев, т.н. "ревью" кода
другим человеком, не выявляет большинство ошибок в работе этого кода.
(кроме элементарных случаев, типа проверки на NULL).
Т.к. для того, чтобы проверить чужой код от и до, ревьюер должен полностью понять,
что этот код должен делать и как он работает на самом деле. Зачастую, на это нужно еще
больше времени, чем ушло на написание кода у автора. А время, как известно - деньги.
Так что чаще всего, ревьюинг как раз проверками на NULL и ограничивается.> Я думаю, что разработчикам С/С++ компиляторов нужно делать больший упор на анализ, чтобы такие ошибки можно было отлавливать если не прямо в IDE, то хотя бы на этапе компиляции.
Согласен. И попытки это сделать уже предпринимаются: например LLVM, уже может сам расставлять
retain/release для Objective-C кода, и показывать прочие чудеса анализа.
И такие проекты как Coverity должны помочь.
> С появился, как ответ на определенную ситуацию,Си появился поскольку у авторов было желание запустить убогий простаивающий в углу никому не нужный комп. Лучше бы оно потратили время на выбивание у начальства денег на мейнфрейм с нормальными языками от IBM.
>в точности также, как позднее и С++.
Конечно же совсем не так.
> Я думаю, что разработчикам С/С++ компиляторов нужно делать больший упор на анализ, чтобы такие ошибки можно было отлавливать если не прямо в IDE, то хотя бы на этапе компиляции.
Системам статического анализа 100 лет. Посмотрите lint например. Lint first appeared (outside of Bell Labs) in the seventh version (V7) of the Unix operating system in 1979. Не помогает.
http://softwareintegrity.coverity.com/coverity-5-5-webinar-r...Вот скажите, как вон та песта может быть "... over 15 years of technology marketing experience with expertise in code governance, static analysis and automation"
Тётке, от силы, лет 27-28 ... ну пусть даже 35!!!
в 12 лет сломала комп у брата. вот как!
это же Director of Product Marketing: они органически неспособны правду говорить.
чувак, тетке около 45.
> чувак, тетке около 45.а на вид ягодка. сразу видно — ни для честно не работала, только трудовой люд обманывала.
>а на вид ягодкаягодка опять
> чувак, тетке около 45.Фотошоп рулит!?
Срач java vs Qt и C# vs Qt уже был?
> Срач java vs Qt и C# vs Qt уже был?неа, можешь начинать.
Начинаю. Библиотека Qt - это неплохая поддержка для "голого" С++. Сравнивать C# и java нужно именно с Qt, а не с C++.
> Начинаю. Библиотека Qt - это неплохая поддержка для "голого" С++. Сравнивать C#
> и java нужно именно с Qt, а не с C++.ну и с чем тут спорить? ты что-нибудь провокативное вкидывай.
> ну и с чем тут спорить? ты что-нибудь провокативное вкидывай."PHP - глобальное и надежное решение для серьёзного бизнеса, а на сипипи пишут лунупсоеды-недоучки за еду"
> "PHP - глобальное и надежное решение для серьёзного бизнеса, а на сипипи
> пишут лунупсоеды-недоучки за еду"уйди, мы тут о Qt!
Этот вентилятор уже так забросали, что он давно перестал крутиться...
Сравнивать языки принято с языками. а библиотеки с библиотеками. Выше было.
> Сравнивать языки принято с языками. а библиотеки с библиотеками. Выше было.ок. тогда от жабы отдираем JVM, а от c# .Net. никак иначе. это — рантаймовые *библиотеки*.
почему не проанализировали plan9? это ж цитадель высокой мысли и идеальных решений, настолько идеальных, что аж сферических. пишут ли там с ошибками? (прости господи меня за такое вольномыслие)
Иногда такие быстрые исправления ошибок просто пужают.Вон, несколько лет назад, valgrind показывал, что в OpenSSL неинициализированная переменная, Debianовцы "исправили" ошибку, и всё было хорошо. А потом оказалось, что исходные переменные для создания ключей стали прогнозируемы.