Готовится к выходу (http://seclists.org/dailydave/2008/q1/0132.html) первая версия неформального стандарта, обобщающего требования и рекомендации по созданию безопасных программ на языке Си - "CERT C Secure Coding Standard (https://www.securecoding.cert.org/confluence/display/seccode...)" и Си++ - "CERT C++ Secure Coding Standard (https://www.securecoding.cert.org/confluence/pages/viewpage....)". Релиз документа будет выпущен 18 апреля, до этого момента разработчики будут рады выслушать замечания и предложения.
Кроме того, можно отметить две ссылки:- "10 Secure Coding Practices (https://www.securecoding.cert.org/confluence/display/seccode...)" - десять простых правил для разработчиков безопасного ПО;- "2007 CERT Research Annual Report Published (http://www.cert.org/research/2007research-report.pdf)" (PDF, 3.5Мб) - достижения CERT в разработке теоретического базиса и инженерных методов по обеспечению безопасности критических систем и сетей.
URL: http://seclists.org/dailydave/2008/q1/0132.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=14751
А существует стандарт безопасного "программирование" на PHP ?
как и для любого другого средства разработки веб-приложений, стандарт простой:
не верь данным приходящим снаружи.Для этого думать иногда приходится, что зачастую делать php-програмеры не любят, но это все таки не вина php, как мне кажется.
ну не только это, еще хотя-бы деление на нуль тоже проверить не помешает .. ;)
Ошибка в ссылке на top 10 secure coding
https://www.securecoding.cert.org/confluence/display/seccode...
Одна из единиц, полезных ссылок и новостей за этот год!
Мыши плакали и кололись, но продолжали упорно жрать кактус.
+1Похоже на попытку повесить броню на деревянный самолёт, когда другие у же давно поняли, что самолёты проще из металла строить.
Металл это что ?
Паскаль ^_^
Esli ne secret, chto vi imeete v vidu pod "derevyanniy samolyot" i chto togda po vashemu "metal"?
Ага, когда то мой товарищ си-плюс-плюсник был в замешательстве, читая книжку какогото корифея C++, в ней в одном разделе писалось, что его нельзя ипользовать для написания высоконадежных программ, особенно связаных с критическими вещами и безопасностью жизни, приводились примеры почему.
В качестве альтернатив упоминалась АДА, и еще что то, непомню
C - это инструмент, которым можно либо легко и удобно работать, а можно отрезать себе руку. Всё зависит от вашей квалификации. Например: все должны есть ложками, вилками можно выколоть себе глаз ненароком. Прокатит такое в реальной жизни ? Например: у мебели не должно быть острых углов, а все стены должны быть оббиты мягким материалом - добро пожаловать в дурдом. В С программисту предоставлена свобода: не хочешь использовать множественное наследование - не используй, не хочешь использовать голые указатели - не используй.У нас один "корифей" преподавал язык Ада в универе таким образом: говорил "множественное наследование - это ужас, мучения и смерть. В Аде такой бяки нет!" и тут же рисовал пример на Аде: подключение кучи пакетов, и написание альясов к ним. Разобрать потом, что откуда он дёргает было невозможно. Реально адский язык.
По поводу мышей: сначала мне говорили: пролог - язык будущего, С - мёртв. Потом мне говорили Паскаль - язык настоящего, а С мёртв. Потом мне говорили Java - язык завтрашнего дня, С - мёртв окончательно, наконец-то изобрели СHash - теперь С точно помер... А С всё живёт и живёт. И Борланд ворует в свой Delphi сишные фишки, и cvsup на С переписали наконец-то (с ультрабезопасной модулы, придуманной гениальным Виртом), и стандарты вот разные принимают. Странно как-то для мёртвого языка. Нет? С\С++ - это идеальный компромисс между быстродействием и надёжностью, всё остальное академические поделки, представляющие лишь научный интерес.
>С\С++ - это идеальный компромисс между быстродействием и надёжностью,
>всё остальное академические поделки, представляющие лишь научный интерес.полностью поддерживаю !!!
>C - это инструмент, которым можно либо легко и удобно работать, а
>можно отрезать себе руку. Всё зависит от вашей квалификации. Например: все
>должны есть ложками, вилками можно выколоть себе глаз ненароком.Однако, согласитесь, кусок мяса есть вилкой удобнее, чем ложкой. А суп вилкой одолеть будет еще сложнее. Так что не забудем, для какой задачи мы используем язык.
>всё остальное академические поделки, представляющие лишь научный интерес.
зачастую далеко не академические, иногда не поделки, и если до сих пор существуют, значит к ним есть интерес в широких массах... ;-)
Сразу скажу я не программист, но в начале пример
int avg(int a, int b) { return (a + b) / 2; }
поверг меня в шок и ужас
http://bugtraq.ru/library/programming/badcode.html
статья по линку - супер !
статья по линку очень смешная
это еще автор всего опенсоурс нерасматривал....там еще хуже)))))
но речь не о том
все что рассматривал автор имет смысл ТОЛЬКО если это разработка ведеться группой разработчиковно если это работа двух трех девелоперов
то поверте ничего страшного в int avg(int a, int b) { return (a + b) / 2; }
я невижу
если изначально вся программа использующая это продумана
и уже изначально a и b не будут приходить такими.....есть много примерв
где к примеров программ очень граммотно написаных
делают write(fd, element->buffer, element->length) когда
element = NULL;
НО
список из которого это читаеться никогда не будет включать таких NULL элементов
но это ньюансы
Чёт автор перемудрил. Если ему не нравится
int avg(int a, int b) { return (a + b) / 2; }
то легко можно переписать так:
int avg(int a, int b) { return 0.5*a + 0.5*b; }
Без условных переходов, переполнений и "левых" функций типа sign().
А ничего, что функция возвращает int (целое), а возвращаемое значение вычисляется делением на 2? :) Т.е. возвр. значение должно быть числом с плавающей точкой.
Тогда уж логичнее
int avg(int a, int b) { return a/2 + b/2; }
хотя умножение на 0.5 тоже нормально работает. :)
> Тогда уж логичнее
> int avg(int a, int b) { return a/2 + b/2; }Подумайте, что вернет этот вариант avg(1,1)
Вернёт 0, но речь то о том что нужно избежать переполнение буфера, а точность возвращаемого результата зависит от поставленной задачи. Может мне и нужно чтобы функция в таком варианте параметров возвращала 0, главное чтобы не было переполнения. :)
Здесь не переполнение буфера, а переполнение переменных/регистров
>> int avg(int a, int b) { return a/2 + b/2; }
>Подумайте, что вернет этот вариант avg(1,1)1/2 + 1/2 = 1
Не знаю где тут выкопали 0 %)
>>> int avg(int a, int b) { return a/2 + b/2; }
>>Подумайте, что вернет этот вариант avg(1,1)
>
>1/2 + 1/2 = 1
>
>Не знаю где тут выкопали 0 %)это на бумаге 1 а в программе 0
Жуткое решение предлагает автор, такое мог написать разве что школьник, только изучающий программирование. Если имеется вероятность переполнения, то куда правильней использовать более вместительный тип данных, например, если int - это 32 бита, то функция будет выглядеть так:int avg(int a, int b) { return ((int64)a + (int64)b) / 2; }
Однако, на ассемблере можно сделать еще элегантнее с тем же самым типом :)
Лучше сразу тип данных с плавающей запятой, тогда и округление будет точнее.int avg( int a, int b) {
return (int) lround( ((double)a + (double)b) * 0.5);
}
нет не лучше, ибо совсем другие инструкции процессора и совсем другие такты
FPU достаточно быстро работает на современных процессорах, не надо ля-ля. Ничуть не медленней АЛУ. На конвертацию да, придётся потратиться...Но я бы стал так писать, если что - ибо пара тактов в нерасчётной задаче абсолютно некритична.
да конечно можно кивать в сторону скорости процессоров, и писать проги в стиле "лижбы работало", но применять решения с плавающей точкой, там, где все элементарно делается целыми числами, мягко говоря не разумно.. хотя, конечно, у каждого свой взгяд на жизнь...
Согласен. Но:
1. Смотря какого процессора. На i686 преобразование int <-> double займет лишь несколько тактов.
2. В исходной задаче нигде не было сказано, что пользоваться следует только целочисленной арифметикой. ;)
в твоем варианте результат будет неверен оно будет усечено >int avg
результат будет верен, ничего не потеряется :)
>Жуткое решение предлагает автор, такое мог написать разве что школьник, только изучающий
> программирование.Полностью не согласен!! Пустые штампы без аргументов%)
> Если имеется вероятность переполнения, то куда правильней использовать более
>вместительный тип данных,Да, "куда правильней"??
> например, если int - это 32 бита, то
>функция будет выглядеть так:
>
>int avg(int a, int b) { return ((int64)a + (int64)b) / 2;
>}Я считаю просто лишние операции на преобразование и вычисление для x86 например.
Так а если у нас аргументы сами уже будут avg(long long int a, long long int b) что тогда?? ;))
К тому же с переносимостью тоже не всё ясно - С99??На том же сайте обсуждается более эффективый алгоритм.
>Однако, на ассемблере можно сделать еще элегантнее с тем же самым типом
PS. В тему!! http://www.wasm.ru/article.php?article=onebyte
Когда будет аналогичный стандарт по java?
При умножении на 0.5 происходит автоматическое приведение к типу double. Приведение к int происходит только когда уже вычислено значение выражения, так что в таком варианте avg(1,1) вернёт 1.Имеем два преобразования int в double, три операции с плавающей точкой, и обратное преобразование double в int. В варианте из статьи имеет два вычисления знака int, один переход и две операции с int( вычисление знака тоже можно сюда отнести, так что будет всего 4 с int и один if).
>что будет всего 4 с intхотя нет,их ещё и сравнить надо