информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Не только, но в общем да, наиболее полезен он именно в C 08.10.08 01:35  Число просмотров: 2354
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> По твоему выходит, что C - это краеугольный камень. Не буду
> спорить. Для меня C - такой же мамонт как алгол ;)
> Трахайтесь дальше со своими указателями, буферами и
> городите огороды в виде SAL ;)

Только для того, чтобы не трахаться с указателями и буферами это не к плюсам, а жабам-додиезам.

> А вот нахрена SAL нужен в C++ - не ясно. "Чую дело

Ну вот неконстантная ссылка это out или inout? Кроме того, плюсы с гораздо бОльшими проблемами биндятся к другим языкам, чем C (тут тебе и собственные схемы мангляния у каждого компилятора, и собственная BPI для виртуальных таблиц, виртуального и множественного наследования,и невозможность заэнфорсить конктрукцию/деструкцию в других языках, и несовместимость обработки исключений и много чего еще). Именно поэтому API, которые предполагается использовать с другими языками/компиляторами делаются обычными PlainC-функциями (и при желании чуть выше заворачиваются в плюсовые обертки). Вон весь WinAPI - заSALен и это хорошо. Даже при вызове WinAPI из C++ кода хорошо.

> бесовское, а обосновать не могу" - всмысле, что вроде как и
> что-то полезное (судя по редким восторженным репликам), но
> куда это воткнуть, и главное - для чего, фантазии не
> хватает.
Да в общем повышает избыточность кода, что позволяет находить чуть больше ошибок статически. Ровно для тех же целей существует статическая типизация. Чуваки, более склонные к динамической типизации тоже ни хрена не понимают, почему это они не могут (без дополнительных извращений типа boost::any) в одном векторе хранить и строки, и инты, и лямбды.
<programming>
[C++] кто использует MS SAL аннотации в коде? 04.10.08 19:36  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
В принципе удобно в определениях:
void f(__in int a)
{
}

...
...
...
но так же удобно и где-то в коде: f(__in 10); Для IDL - так вообще это норма.
[C++] от слова к делу 08.10.08 06:44  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Сегодня предложил тим-лидам высказаться о возможности использовать это в наших проектах.

1) Реакция разная. 99% всего кода компании это C++ std-based код, и возникает вопрос зачем это нужно если мы используем const std::string& parameter, std::vector, map и т.д. (утрирую). С дугой стороны, если учесть, что внури С++ кода есть тонны мест, где торчат уши достаточно низкоуровневых прямых вызовы RTL/API, где есть тонны мелких функций обработки буферов стреамов, строк, шаред мемори стораджей, и т.д. - вопрос о нужности SAL для меня однозначный. Я скорее всего буду использовать везде в коде С++, где это уместно (если начальство не запретит).

2)Есть вопрос - насколько это портабельно. Действительно сложно предположить возможность портить миллионы строк кода для Windows на другую платформу. Здесь возразить нечего. Хотя я вообще не сторонник создания портабельного кода для Windows/MAC/.......

3)Есть также вопрос - как указано в http://blogs.msdn.com/michael_howard/archive/2006/05/19/602077.aspx это работает только на "...that can help static analysis tools, such as the /analyze switch in Visual Studio 2005 Team System and Visual Studio 2005 Team Edition for Developers..."

Действительно, этонеработает, например, на Express edition 2005:
1>Compiling...
1>cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler

Но вот если собрать проект в VC++ 2008 даже Express Edition с опцией '/analyze':

#include "stdafx.h"
#include <windows.h>

void FillString(
      __out_ecount(cchBuf) TCHAR* buf,   
      size_t cchBuf,   
      char ch) {  

  for (size_t i = 0; i < cchBuf; i++)   {     
    buf[i] = ch;   
  } 
} 

int _tmain(int argc, _TCHAR* argv[])
{
	TCHAR buf[100];
	FillString( buf, 102, 0);
	FillString( NULL, 102, 0);
	return 0;
}


---

то получим следующие варнинги (что и нужно):

1>c:\users\val\documents\visual studio 2008\projects\sal\test1\test1.cpp(21) : warning C6202: Buffer overrun for 'buf', which is possibly stack allocated, in call to 'FillString': length '204' exceeds buffer size '200'
1>c:\users\val\documents\visual studio 2008\projects\sal\test1\test1.cpp(22) : warning C6309: Argument '1' is null: this does not adhere to function specification of 'FillString'
А портирование данной конкретной фичи достигается путем вырезания всего SAL препроцессором 08.10.08 07:59  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
You are right, but it is up to the management to decide what... 08.10.08 17:07  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
You are right, but it is up to the management to decide what is good for the company with respect to “porting”. Yesterday, I told the same (as you are saying) to ours team leads. Will see. I personally find new MS features very useful especially for the issues discussed: calls of RTL/WinAPI, and low level programming.
сорри, а для чего ??? 06.10.08 16:18  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> В принципе удобно в определениях:
> void f(__in int a)
> {
> }
>
> ...
> ...
> ...
> но так же удобно и где-то в коде: f(__in 10); Для IDL - так
> вообще это норма.

void f( int a ) - IN.
void f( const int& a ) - IN.
void f( int& a ) - OUT.

Все прекрасно описывается средствами языка. Зачем втаскивать в текст дублирующие конструкции ?
SAL не ограничивается in и out 06.10.08 22:24  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> void f( int a ) - IN.
> void f( const int& a ) - IN.
> void f( int& a ) - OUT.

Что делать в C?
Что делать с IN OUT параметрами? Что делать с OPTIONAL параметрами (в C)? Что делать со всякими __out_ecount (который позволяет находить переполнения буфера)? И т.д..

> Все прекрасно описывается средствами языка. Зачем
> втаскивать в текст дублирующие конструкции ?
Не все, не прекрасно и не дублирующие :-)
Все равно не понятно 07.10.08 13:19  
Автор: PS <PS> Статус: Elderman
Отредактировано 07.10.08 13:23  Количество правок: 1
<"чистая" ссылка>
> > void f( int a ) - IN.
> > void f( const int& a ) - IN.
> > void f( int& a ) - OUT.
>
> Что делать в C?
> Что делать с IN OUT параметрами? Что делать с OPTIONAL
> параметрами (в C)? Что делать со всякими __out_ecount
> (который позволяет находить переполнения буфера)? И т.д..
>
> > Все прекрасно описывается средствами языка. Зачем
> > втаскивать в текст дублирующие конструкции ?
> Не все, не прекрасно и не дублирующие :-)

1. А что делать в ALGOL, LISP и других языках ? (это к вопросу о "C")
2.
void f( __out_encount(n) char* b, int n )
{
memset( b, 0, 2*n );
}

Скомпилится ? С варнингами - да. А можно и без варнингов. Запустится - да. Отработает - да. Память порушит - да.
И х. тогда было огород городить ?

/*!
@param out_str out строка заполненая n ASCII нулями
@param n in количество ASCII нулей для заполнения
*/
void f( std::string& out_str, int n )
{
out_str.append( n, '0' );
}

Память порушит - нет. Что in, что out видно ? да. SAL использован ? нет.

В каком то языке(компиляторе), то ли в VB, то ли в дельфи есть возможность при компиляции устанавливать: передаются параметры по значению или по ссылке.
И один и тот же код
function integer f( integer a){ a = 9; }
при разных ключах компиляции будет вести себя по разному.
Тут действительно SAL необходим ;)
VS не поддерживает ни алгол ни лисп 07.10.08 23:17  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> 1. А что делать в ALGOL, LISP и других языках ? (это к

VS не поддерживает ни алгол ни лисп

> вопросу о "C")

А вот C - поддерживает.

> 2.
> void f( __out_encount(n) char* b, int n )
> {
> memset( b, 0, 2*n );
> }
>
> Скомпилится ? С варнингами - да. А можно и без варнингов.
> Запустится - да. Отработает - да. Память порушит - да.
> И х. тогда было огород городить ?

Если с ворнингами - то этого достаточно. Вон ядерный код вообще компилируется с treat warning as errors. И все - не скомпилится. Если же человек увидел ворнинг и вместо того, чтобы разобраться в проблеме просто подавил его ключами - что ж сам идиот.

Вот здесь есть пример того, как это работает.
http://blogs.msdn.com/michael_howard/archive/2006/05/19/602077.aspx

> /*!
> @param out_str out строка заполненая n ASCII нулями
> @param n in количество ASCII нулей для заполнения
> */
> void f( std::string& out_str, int n )
> {
> out_str.append( n, '0' );
> }
>
> Память порушит - нет. Что in, что out видно ? да. SAL
> использован ? нет.

Плюсовые обертки это конечно хорошо, но к примеру в C их нет. Да и при стыковке с WinAPI все равно надо разворачивать и вытаскивать наружу указатели и счетчики символов.
Т.е. SAL хорошо только для C ? 08.10.08 00:59  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> > 1. А что делать в ALGOL, LISP и других языках ? (это к
>
> VS не поддерживает ни алгол ни лисп
>
> > вопросу о "C")
>
> А вот C - поддерживает.
>
> Плюсовые обертки это конечно хорошо, но к примеру в C их
> нет. Да и при стыковке с WinAPI все равно надо
> разворачивать и вытаскивать наружу указатели и счетчики
> символов.

По твоему выходит, что C - это краеугольный камень. Не буду спорить. Для меня C - такой же мамонт как алгол ;) Трахайтесь дальше со своими указателями, буферами и городите огороды в виде SAL ;)
А вот нахрена SAL нужен в C++ - не ясно. "Чую дело бесовское, а обосновать не могу" - всмысле, что вроде как и что-то полезное (судя по редким восторженным репликам), но куда это воткнуть, и главное - для чего, фантазии не хватает.
Не только, но в общем да, наиболее полезен он именно в C 08.10.08 01:35  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> По твоему выходит, что C - это краеугольный камень. Не буду
> спорить. Для меня C - такой же мамонт как алгол ;)
> Трахайтесь дальше со своими указателями, буферами и
> городите огороды в виде SAL ;)

Только для того, чтобы не трахаться с указателями и буферами это не к плюсам, а жабам-додиезам.

> А вот нахрена SAL нужен в C++ - не ясно. "Чую дело

Ну вот неконстантная ссылка это out или inout? Кроме того, плюсы с гораздо бОльшими проблемами биндятся к другим языкам, чем C (тут тебе и собственные схемы мангляния у каждого компилятора, и собственная BPI для виртуальных таблиц, виртуального и множественного наследования,и невозможность заэнфорсить конктрукцию/деструкцию в других языках, и несовместимость обработки исключений и много чего еще). Именно поэтому API, которые предполагается использовать с другими языками/компиляторами делаются обычными PlainC-функциями (и при желании чуть выше заворачиваются в плюсовые обертки). Вон весь WinAPI - заSALен и это хорошо. Даже при вызове WinAPI из C++ кода хорошо.

> бесовское, а обосновать не могу" - всмысле, что вроде как и
> что-то полезное (судя по редким восторженным репликам), но
> куда это воткнуть, и главное - для чего, фантазии не
> хватает.
Да в общем повышает избыточность кода, что позволяет находить чуть больше ошибок статически. Ровно для тех же целей существует статическая типизация. Чуваки, более склонные к динамической типизации тоже ни хрена не понимают, почему это они не могут (без дополнительных извращений типа boost::any) в одном векторе хранить и строки, и инты, и лямбды.
It does not duplicate the existing semantics. 06.10.08 21:48  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
[C++] Я пользовался в kernel-коде 04.10.08 21:54  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> В принципе удобно в определениях:
> void f(__in int a)
> {
> }
>
> ...
> ...
> ...
> но так же удобно и где-то в коде: f(__in 10); Для IDL - так
> вообще это норма.

IN, OUT, OPTIONAL. Раньше они были пустыми дефайнами, сейчас вроде компилятор МОЖЕТ извлечь какую то информацию (к примеру выдать ворнинги или соптимизировать чего-то), так что сейчас это не только удобно, но еще и МОЖЕТ привести к более правильными результатам
По полной программе (т.е. не может, но "a must") это... 05.10.08 07:56  
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 05.10.08 16:54  Количество правок: 1
<"чистая" ссылка>
> IN, OUT, OPTIONAL. Раньше они были пустыми дефайнами,
> сейчас вроде компилятор МОЖЕТ извлечь какую то информацию
> (к примеру выдать ворнинги или соптимизировать чего-то),
> так что сейчас это не только удобно, но еще и МОЖЕТ
> привести к более правильными результатам

По полной программе (т.е. не МОЖЕТ, но "a must") это реализовано только для "managed" кода, например C#. Причём, для managed кода это работает не только на уровне определения, но и вызовов (т.е. нельзя в определении фунции написать "ref", а при вызове функции опустиить "ref")... Жаль что этого нет в С++ (имею ввиду в non-managed С++).
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach