Здравствуйте, Sinclair, Вы писали:

S>Практика показывает, что изолировать машину от внешнего кода можно только в тепличных условиях типа АЭС или МКС. Во всех остальных случаях даже ломать не надо — "сами все предложат и сами все дадут", (с) Булгаков.

...

S>Основные пути проникновения вредоносного кода:
S>- программы, запускающие внешний код:
S>-- Мэйлеры и браузеры, рискующие делать глупости типа запуска превью для приехавших данных
S>-- средства автоматизации, исполняющие скрипты VBA
S>- дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер
S>- развод лохов на запуск аттачментов с вирусами


Ага, с этим не поспоришь. Вот только тема нашего разговора несколько ограничена тематикой Safe VS Unsafe. В рамках которой имеет смысл обсуждение лишь одной проблемы "дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер".

Здравствуйте, dimon0981, Вы писали:
D>Ага, с этим не поспоришь. Вот только тема нашего разговора несколько ограничена тематикой Safe VS Unsafe. В рамках которой имеет смысл обсуждение лишь одной проблемы "дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер".
Совершенно верно. Потому, что CAS — это уже managed vs unmanaged. Каюсь, извиняюсь за оффтоп. Караю себя недельным баном начиная с 28 числа. Заодно и в командировку скатаюсь.

Здравствуйте, FR, Вы писали:

FR>Нет пока стороники C# тут рекламируют N (они бедняги на C# писать уже не хотят, а на N пока не могут) уже выходит второй релиз программы на C++

Языком он выходит. А "сторнники" давно и плодотворно работают.

Здравствуйте, dimon0981, Вы писали:

D>Убедил. Давай сюда эту самую управляемую ОС — Singularity . Где ее можно скачать/купить? Надеюсь она обеспечит мне и пользователям моего софта чувство защищенности и массу других обещаемых "вкусностей".

To be run, a piece of code must be added to the system by the Singularity installer.
...
In the current implementation the entire installation process takes place offline with an installation becoming visible only at the next system boot. This purely off-line installation may be trivially augmented with on-line installation, but on-line installation has not yet been required by our usage scenarios.

Насколько я это понимаю, одна из "вкусностей" — разработка методом edit-compile-install-reboot-test.

Здравствуйте, Трурль, Вы писали:

Т>

To be run, a piece of code must be added to the system by the Singularity installer.
Т>...
Т>In the current implementation the entire installation process takes place offline with an installation becoming visible only at the next system boot. This purely off-line installation may be trivially augmented with on-line installation, but on-line installation has not yet been required by our usage scenarios.

Т>Насколько я это понимаю, одна из "вкусностей" — разработка методом edit-compile-install-reboot-test.
Обрати внимание на выделеное.

Здравствуйте, Left2, Вы писали:

L>Ну а во-вторых — strncpy не менее стандартная чем strcpy. И очччень ненамного медленне работает.

Вот такое утверждение я бы не стал делать

char * __cdecl strcpy(char * dst, const char * src)
{
        char * cp = dst;
        while( *cp++ = *src++ )
               ;               /* Copy src over dst */
        return( dst );
}


char * __cdecl strncpy (
        char * dest,
        const char * source,
        size_t count
        )
{
        char *start = dest;
        while (count && (*dest++ = *source++))    /* copy string */
                count--;
        if (count)                              /* pad out with zeroes */
                while (--count)
                        *dest++ = '\0';
        return(start);
}

итого две лишние (как минимум) команды на пересылку каждого байта — && и --. А сколько их реально — это от компилятора зависит.

char szBuf[100];
int _tmain(int argc, _TCHAR* argv[])
{
    DWORD dwTimeStart = GetTickCount();
    for ( int i = 0; i < 100000000; i++)
        strcpy(szBuf,"adfvhdvghhjvhjvhbvjdhjhjdfhjhjdfbvhjjhbhdfbhjdfhgdhjbghjbhjdbhjdfjbjf");
    DWORD dwTimeEnd = GetTickCount();
    printf("%d\n", dwTimeEnd - dwTimeStart);
    return 0;
}

Release, VC 7, 6,265 мсек

char szBuf[100];
int _tmain(int argc, _TCHAR* argv[])
{
    DWORD dwTimeStart = GetTickCount();
    for ( int i = 0; i < 100000000; i++)
        strncpy(szBuf,"adfvhdvghhjvhjvhbvjdhjhjdfhjhjdfbvhjjhbhdfbhjdfhgdhjbghjbhjdbhjdfjbjf", 70);
    DWORD dwTimeEnd = GetTickCount();
    printf("%d\n", dwTimeEnd - dwTimeStart);
    return 0;
}

Release, VC 7, 9,625 мсек

В полтора раза — не есть "очччень ненамного медленне"


L>И в 99.99% случаев проще забыть о существовании strcpy.

Здравствуйте, AlexLion, Вы писали:

AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов:
AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается
AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается

AL>Вопрос в том — какой бы вы вариант выбрали ( используете ) и почему.


Теоретически почти все небезопасно.

Выделение памяти по new или malloc — безопасно ? Нет, памяти может не хватить. Ну и что, каждый вызов будете окружать catch или __except ? В программе, которая суммарно выделяет не более 1 Мб ? На том основании, что когда-то может понадобиться 100 Мб ?

Создание объектов GDI/USER небезопасно — лимит на 10000 на процесс. Будете проверять каждый вызов CreatePen ?

И т.д.

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

Не вижу смысла в таком тесте. Здесь используется одна и та же строка — да, она тут же легла в кеш и процессор перемалывает одни и те же данные — понятное дело что при таком раскладе каждый такт на счету (мы даже в память не лазим, всё из кеша, причём кеша первого уровня!). В более-менее реальных приложениях выигрыш от strcpy будет минимальным.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Нет пока стороники C# тут рекламируют N (они бедняги на C# писать уже не хотят, а на N пока не могут) уже выходит второй релиз программы на C++

VD>Языком он выходит. А "сторнники" давно и плодотворно работают.

"Интеграция Nemerle и Visual Studio" это конечно хорошо, но тут разговор идет о конечных продуктах сделанных с использованием соответствующих технологий.

PD>Теоретически почти все небезопасно.

PD>Выделение памяти по new или malloc — безопасно ? Нет, памяти может не хватить. Ну и что, каждый вызов будете окружать catch или __except ? В программе, которая суммарно выделяет не более 1 Мб ? На том основании, что когда-то может понадобиться 100 Мб ?

Нет, каждый вызов окружать не буду. Но буду писать так, чтобы вылетевший откуда угодно bad_alloc смог обработаться и при этом все созданные обьекты остались живы. Exception safe не значит что каждая строчка обёрнута try-catch, это заблуждение.

PD>Создание объектов GDI/USER небезопасно — лимит на 10000 на процесс. Будете проверять каждый вызов CreatePen ?

Если отрисовка критически важна в этой программе — то да, буду. Заверну в обёртку и буду кидать exception если что-то обломалось.

PD>И т.д.

PD>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где можно использовать небезопасные конструкции, а где нет.

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

Беру свои слова Re[5]: Safe or Unsafe — this is the question

Автор: Left2
Дата: 22.05.06

насчёт strncpy и strcpy взад В том плане, что в VS 2005 strncpy точно так же deprecated как и strcpy. Но насчёт того чтобы юзать везде (практически везде, кроме тех мест где считают каждый такт) strncpy вместо strcpy — насчёт этого не откажусь никогда

Здравствуйте, FR, Вы писали:

VD>>Языком он выходит. А "сторнники" давно и плодотворно работают.

FR>"Интеграция Nemerle и Visual Studio" это конечно хорошо, но тут разговор идет о конечных продуктах сделанных с использованием соответствующих технологий.

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

Что до C#, то вспомним Янус. Уж как его тут не ругали... Но он есть и работает. А планы по созданию крутого межплатформного С++-варианта так и остались трепом.

Так что факты на лицо.

Здравствуйте, Cyberax, Вы писали:

C>F# работает быстро, но вот Haskell даже портировать не пытаются. На CLR
C>вообще нельзя эффективно делать динамические языки (например, если
C>JITить код из динамического языка в CLR, то можно очень быстро занять
C>всю память — так как код не собирается GC).

Гулупость полнейшая.
1. Haskell статически типизированный язык.
2. С динамическими вызовами в дотнете не хуже чем в любом другом месте.

Единственное, что ожет немного огорчать разработчиков ФЯ — это оврехэд по памяти в 12 байт на каждый объект. Для связанных списков это нескольно избыточно. Но тому же Nemerle это как-то не сильно мешает.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

VD>>>Языком он выходит. А "сторнники" давно и плодотворно работают.

FR>>"Интеграция Nemerle и Visual Studio" это конечно хорошо, но тут разговор идет о конечных продуктах сделанных с использованием соответствующих технологий.

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

Конечно, куда уж нам убогим.

VD>Что до C#, то вспомним Янус. Уж как его тут не ругали... Но он есть и работает. А планы по созданию крутого межплатформного С++-варианта так и остались трепом.

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

Здравствуйте, FR, Вы писали:

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

FR>Конечно, куда уж нам убогим.

А что? На что-то можно посмотретиь?

FR>Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой несколько дней назад.

Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о котором так долго чесали лясы меньшивики.

Здравствуйте, VladD2, Вы писали:

VD>... А вот типобезопасть как класс устраняет ряд трудновыяляемых ошибок и действительно повышает надежность. Правда тоже не устраняет саму проблему.

Есть такая поговорка — "если это не решает проблему, значит оно её создает"

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

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

FR>>Конечно, куда уж нам убогим.

VD>А что? На что-то можно посмотретиь?

У меня нет, я же только лясы точу
И еще ежиков опасаюсь

FR>>Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой несколько дней назад.

VD>Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о котором так долго чесали лясы меньшивики.

А я тут причем? У меня никогда не было планов написания ничего янусообразного

VladD2 wrote:
> FR>Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой
> несколько дней назад.
> Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о
> котором так долго чесали лясы меньшивики.
Thunderbird + RSDN.NNTP

VladD2 wrote:
> Гулупость полнейшая.
> 1. Haskell статически типизированный язык.
Он ленивый. В этом и проблема.

> 2. С динамическими вызовами в дотнете не хуже чем в любом другом месте.
Сравним Python и IronPython?

Здравствуйте, Cyberax, Вы писали:

>> Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о
>> котором так долго чесали лясы меньшивики.
C>Thunderbird + RSDN.NNTP

Как по-твоему на чем RSDN.NNTP написан? И почему не на С++?