В чём новость? Они уже давно забанили половину стандартных функций C и C++ и заменили их на "безопасные" варианты. ЭмСи++, с блекджеком и шлюхами.

И да, проверять параметры в рантайме _постоянно_ - это маразм.

Чем бы дитя не тешилось…

А при чем здесь Linux? Оно что так сильно надо, что надо пинать разработчиков gcc?

Microsoft собирается зохавать мир

> В качестве альтернативы предлагается использовать функцию memcpy_s(), которая уже реализована в Visual C++

Мне кажется или кто-то хочет посадить на вижуал студию побольше софта под венды?

>Microsoft планирует забанить memcpy
Что это делает на лоре?
Мне даже не смешно. Да и под стол я давно упал.

> В gcc нативной поддержки memcpy_s() пока нет.

А ожидается?
Разве GCC ориентирован на применение технологических решений от MS вдогонку?

>проверять параметры в рантайме _постоянно_ - это маразм.
Это приведёт k несравненному приросту скорости в win7

>Developers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s, a newer command that takes an additional parameter delineating the size of the destination buffer.

Эээ… и ЭТО и есть супер-мега-фича?

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

казалось бы, при чём тут Linux?

И что? 

В каментам к новости ясно сказано: "Ничто не мешает использовать функцию memcpy_s с неверным размером назначения намеренно или ненамеренно. Код как падал, так и будет падать."

Дело не в функциях, а в программистах.

Очевидно, микрософтовские новации связаны с переизбытком быдлокодеров в микрософте, в чём пропадают последние сомнения. :)

Микрософт в своем репертуаре. Я даже не удивлен.

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

> которая уже реализована в Visual C++. В gcc нативной поддержки
> memcpy_s() пока нет.
Вообще-то это библиотечная функция, при чём тут gcc?
В gcc, насколько мне известно, не хотели делать такую
тупизну. Хотели, чтобы компилятор сам отслеживал и проверял
размер буферов памяти. В простейших случаях он их сам и
вычислит, в более сложных - могут потребоваться аннотации
или даже специальный тип указателя. Но это лучше, чем так...

А причём тут Linux?
Создатели gcc и других свободных компиляторох чихать хотели на решение мелкомягких..

> [...] и не должен пытаться их запрещать такими макросами как #pragma warning(disable:4996)

а такими:

#define memcpy(dst,src,size) memcpy_s(dst,size,src,size)

?

зы: неужели у мелкософта столько криворуких быдлокодеров, что пришлось делать такой костыль?

ззы: закапывайте.

Есть предложение проверить проверяющего новости у психоаналитика. Может быть ему лучше на windows.org.ru будет?

>И да, проверять параметры в рантайме _постоянно_ - это маразм.

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

Полный бред. Как уже сказали, это не поможет вообще. Си всё равно останется си со всеми недостатками, а теперь ещё и с тормозами и быдлокодерами, слепо уверенными в правильности их поделий.

И да, линукс и опенсорс тут вообще не при чём. Кроссплатформенным программам этот беспомощный SDL всё равно не нужен.

PS а std::vector & operator=(const std::vector & vec) по их мнению безопасен?

Вендекапец таки настанет?

Лорчую.

Баяну сто лет в обед. В толксы.

Для тех, кто спрашивает о том, каким образом это относится к Linux и утверждает про "костыль придуманный Microsoft":

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/coding/303-B...

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1225.pdf

Как видите речь идёт о стандарте, который относится и к UNIX системам.

>Бан будет заключаться в выводе предупреждений C4996 при компилировании кода

Сикьюрити на уровне компилятора - это страшный тупизм. От ошибок и злонамеряний code monkeys компилятор конечно же защитит. Но что если куллхацкир ручками подправит бинарный файл. Если сама ОС не проводит никакой дополнительной верификации испольняемых бинарей - то все это белыми нитками шито.

Безопасное кодирование по заветам Майкрософт часто бысмысленно и беспощадно. В Writing Secure Code советовали использовать WPAaccept и хук-функцию "к нам одиночный SYN с такого-то адреса, будем ли продолжать коннект"? Привет, DOS!

errno_t memcpy_s(
void *dest,
size_t numberOfElements,
const void *src,
size_t count
);

Которая скорее всего реализована, как:

return numberOfElements < count ? E_LIFEISMISERABLE : memcpy(dest,src,count);

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

> Как видите речь идёт о стандарте, который относится и к UNIX
> системам.
Это вроде бы пока что только TR, а не стандарт, может ещё и не примут...
Проверять размер буфера надо на этапе компиляции, а не исполнения.
Хотя это далеко не всегда возможно, вроде бы считается, что код
можно писать так, чтобы такие проверки можно было осуществлять.
И нормально написаный код приводится к такому состоянию без проблем,
и только тогда становится безопасным. И в gcc хотят реализовать
такие проверки, а вот то, что делает Микрософт - таки костыль.
Почему бы тогда ещё и размер входного буфера не передавать?
А то ведь мало ли что за ним лежит: может что-то очень ценное,
что не должно было быть скопировано - это тоже уязвимость.

> Которая скорее всего реализована, как:

#define memcpy_s(dstPtr, dstSize, srcPtr, srcSize) \
        ((!(srcPtr) || !(dstPtr) || (dstSize) < (srcSize)) ? \
         EINVAL : 0 * (int)memcpy(dstPtr, srcPtr, srcSize))

по сцылке же всё написано...

>или дать в руки жабу

"Вы так об этом говорите, как будто в этом есть что-то плохое." (с)

На С писать безопасно могут только роботы (читай кодегенераторы).

> #define memcpy(dst,src,size) memcpy_s(dst,size,src,size)

Причём, я гарантирую это, в чуть менее, чем во всех случаях подобным образом и будут поступать. :)

> Причём, я гарантирую это, в чуть менее, чем во всех случаях подобным
> образом и будут поступать. :)
Зачем, проще варнинг стерпеть. :)

Пользователь "memcpy()" не существует

> Зачем, проще варнинг стерпеть. :)

> Код, соответствующий Security Development Lifecycle (SDL) не должен выводить таких предупреждений при компиляции и не должен пытаться их запрещать такими макросами как #pragma warning(disable:4996)

нэ?

+1 хотел то же самое написать. кстати, по-моему, я уже натыкался на такие затычки в самом WinAPI, правда давно было дело

> не должен выводить таких предупреждений
Ну а вот это он должен делать, чтоли?
> #define memcpy(dst,src,size) memcpy_s(dst,size,src,size)
Сомневаюсь, что должен. Вряд ли кто-то признает такой
код соответствующим чему-либо (SDL), ведь то, что он варнингов
не выдаёт, наверняка ещё не достаточно.

Ну отказ от статических переменных в функциях типа strtok_s() полезнее наверно будет.

хаха. Пусть идут лесом

Это всё только изза того что memcpy это restrict?

Казалось бы причем тут линукс?!

+100!

Они в .NET проверяют _все_ параметры при вызове _всех_ методов. Как по мне - сомнительный подход.

ЗЫ. вообще мне (да и большинству здесь присутствующих) офигенно пофиг на Visual C++, _ихний_ SDL, и Microsoft целиком. Новость не достойна даже толксов.

> Ну а вот это он должен делать, чтоли?

а это как закон: что не запрещено, то разрешено :) запрещено «гасить» варнинги? фигня вопрос, не будем гасить. компилятор не должен видеть memcpy()? он его не увидит, после препроцессора.

кстати, а чем лучше «препроцессинг» путём замены memcpy(dst,src,size) на memcpy_s(dst,size,src,size) вручную (а ведь именно так и будут делать) препроцессинга препроцессором? ^_^' эффективнее сразу попросить: «пожалуйста, не пишите кривой код» =)

в новой ОС Singularity забанены все программы на Си.

>Microsoft планирует забанить memcpy()

Когда уже забанят Microsoft?

> в новой ОС Singularity забанены все программы на Си.

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

вообще-то я ее уже запускал.

нормально работает

> а это как закон: что не запрещено, то разрешено :) Не, про SDL этот у них столько всего написано - читать не охота. :) Но там есть этап Security Review, http://msdn.microsoft.com/ru-ru/library/cc307409(en-us).aspx в результате которого код проверяется комиссией, и эксперт по безопасности должен подпись поставить. За такие хаки он вряд ли распишется, да и, думаю, там ещё много чего есть, через что ЭТО не пройдёт. Но читать не охота. :)

Они вообще обкурились.

Дело не в функции, а в головах.

Всегда можно проверить (в программе), что дестинейшн имеет достаточную длину. Как правило дестинейшн и выделяется нужной длинны.

У M$ совсем плохо с кодерами?

> а это как закон: что не запрещено, то разрешено :)
Не, про SDL этот у них столько всего написано - читать не охота. :)
Но там есть этап Security Review,
http://msdn.microsoft.com/ru-ru/library/cc307409(en-us).aspx
в результате которого код проверяется комиссией, и эксперт по
безопасности должен подпись поставить.
За такие хаки он вряд ли распишется, да и, думаю, там ещё
много чего есть, через что ЭТО не пройдёт. Но читать не охота. :)

СПАСИБО ПОРЖАЛ.

err = memcpy_s(a1, sizeof(a1), a2, 10 * sizeof (int) ); это типично микрософтовский дебилизм.

Вот что есть в gcc:

size_t __builtin_object_size (void * PTR, int TYPE) is a built-in construct that returns a constant number of bytes from PTR to the end of the object PTR pointer points to (if known at compile time).

Это позволяет написать i=2; ... ; MEMCPY(a1+i, a2, 8), которая скопирует 8 элементов, и если a1 был объявлен короче чем 10 элементов, то выдать ошибку в рантайм.

Заодно, как в msvc в функцию передать а1 так, чтобы компилятор знал его размер? В жцц есть расширение void f(int len; char data[len][len], int len)