wcstok_s() vs strtok_s()

Похоже тема оказалась несколько шире заданных вначале рамок 2 конкретных функций.
Вы их развдинули. Хотите продолжить? оk, с удовольствием.

Предположим вы компания производящая антивирусное ПО, как это делает Symantec и вы входите в вышеупомянутый совет по стандартизации языка.
Тогда идеальным языком для вас, точнее то каким бы вы его хотели видеть для остальных пользователей, был бы обернутый в 3 простыни с пожаробезопасным составом и режимом read only язык самого высокого уровня. И чтоб ниже опускаться могли только вы, но никак не потребители вашего ПО. Ясен пень вы будете со многим не согласны. Если вы компания Мелкийсофт, которая даже своё внутреннее устройство документирует весьма скромно и с опаской, и у которой концепция OpenSource до сих пор как кость в горле, в отличии от Никсов, то да. Не трудно догадаться, как вы будете голосовать на Совете. Думаю ещё не забыта эта курьёзная история с поддержкой RAW Sockets, когда её в "форточках" 2000 реализовали полностью. Затем в икспях ограничили. Причём с каждым сервис паком всё больше и больше. А в Viste и 7-ке полностью заблокировали, навечно поставиви печать "Вселенская Ось Зла", фактически опустив их на один уровень c Win95 ft. Win98

По поводу мультиплатформенности. Сейчас получило бурное развитие концепция Виртуализации и это 2-я кость в горле, наряду с OpenSource у компании Мелкосовт. Так как даёт вам возможность, наряду с прочими прыгать с одной Оси на другую, и не быть так жёстко привязанным к одной из них. И в будущих версиях языка и сопутствующих библиотек вас будут стараться ограничить и в этом. Мелкософт кстати уже давно активно продвигает свой обёрнутый в классы язык C#sharp, так как видимо MFC не оправдал всех надежд в плане задуманного. И это всё таки всего лишь библиотека, а реализовать сами ограничения можно только на уровне самого языка. При данных условиях сомнительно, что компания будет поддерживать С++ в ущерб Сsharp.

Цитата

Если тебя не надо предупреждать о потенциально опасных Стандартных функциях, прими мои поздравления

80% всей библиотеки CRT небезопасна, загляни в реализацию функций, практически всё реализовано с помощью одних указателей и базовых типов.
Больше половины CRT уже одели в безопасные обёртки с префиксом _s. (по теме: пример ещё одного костыля wcsncpy_s). Может быть уже проще тогда всю библотеку запретить по этой причине, и не ломать свой моск прикрываясь фальшивой заботой о кодерах?

Давайте в придачу ещё и Assembler запретим, ведь он на 100% небезопасен и все без исключения сядем программировать за "решёткой" C# ! Мы ведь такие опасные, нам место только там.
(๏̯͡๏) ̿̿ ̿̿ '\\з=

Цитата

Неспроста эти все _s().

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

push_s dy; dx
mov_s hInst, eax_s
call_s безопасная_Функ.

За пример эксплойта отдельное спасибо ) не часто встретишь такого откровенного человека.
P.S. По поводу С++ и нового страндарта. Обычно о данном языке говорят: плюсов много, но и минусов не мало.
Жаль, что минусов в последнее время становиться всё больше и больше.

Цитата zzz7net @ 17.02.11, 02:24

Похоже тема оказалась несколько шире заданных вначале рамок 2 конкретных функций.
Вы их развдинули. Хотите продолжить? оk, с удовольствием.

Ты прав. Эти функции тесно касаются безопасного программирования, и в этом контексте я не хотел заостряться только на них. Ибо тем вообще касающихся безопасного программирования мало. Кроме того, эти функции весьма необычны своей опасностью.
К моему сожалению конструктивных ответов от тебя не было и нет.
Дальше идёт оффтоп, надеюсь, последний в этой теме. Могу перетащить в холивары, там можно разговаривать, не особо заморачиваясь фактами. Но совсем без фактов всё равно не долго.
По поводу компаний, производящих антивирусное ПО, у тебя там чушь написана. Их мало заботят возможности языков программирования. Если язык Тьюринг-полный, он подходит для создания зловредов. По поводу MS у тебя информация 15-летней давности. Компания MS уважает OpenSource, и у неё хватает открытых продуктов. Тот факт, что она не желает открывать сырцы на все свои продукты, не более чем ставит её на один уровень, например, с автокорпорациями, также озабочеными своими патентами. А уж качество её проприетарных продуктов дадут фору многим открытым. Это факт, достаточно сравнить количество выпускаемых ею заплаток для своих продуктов и объёмы баг-треков для типичных открытых и соотнести хоть с объёмами на диске, хоть с количеством строк в сырцах. (К слову. ИМХО. Я не люблю OpenSource, потому что он способствует выпускать некачественные продукты, ибо зарабатывает на поддержке. Проприетарные вещи поддерживаются бесплатно, а значит закрытый код выгодно выпускать качественным.)
Касательно всего остального... но комментс. Боюсь, спорить с человеком, совершенно не знакомого с предметом спора, у меня желания не будет. Начни хотя бы с осмысления того, что использование "сырых" указателей не есть небезопасное программирование. Или с того, что MFC - это библиотека, а .NET - платформа. У тебя какой-то слишком узкий взляд на технологии проектирования.

Мин такой сценарий в голову как-то не пришел, просто потому, что я уже привык проверять все входящие извне данные. Если сказанл, что размер записи должен быть, скажем, не более 1К слов, значит если придет 1К+1, это ошибка во входных данных.

amk, я к тому, что уязвимости могут запросто выплыть откуда не ждали. Человеческий фактор - он такой, что 322 раза напишешь правильно, а в 323-й глаз возьми да и замылься, и разумеется именно этот билд окажется в релизе.
Так что наличие _sекьюрных функции недооценивать не стоит, у компилятора с глазами всё в порядке.

Сообщение отредактировано: Qraizer - 18.02.11, 03:42