Компания Red Hat инициировала (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm) процесс удаления приложения "K" в следующей версии стандарта языка Си. Приложение K было добавлено в нынешний стандарт C11 и включает разработанный компанией Microsoft набор функций "*_s" с интерфейсом для проверки границ буферов. Проблема состоит в том, что данный интерфейс был добавлен в стандарт под давлением (https://sourceware.org/ml/libc-alpha/2014-08/msg00151.html) "спонсора" без предварительной проверки на практике.
В итоге, недоработки архитектуры данного механизма и проблемы (https://sourceware.org/ml/libc-alpha/2014-08/msg00185.html), всплывшие при попытках создания практических реализаций, привели к тому, что данный интерфейс на практике нигде не реализован (https://sourceware.org/ml/libc-alpha/2014-08/threads.html#00133) и не применяется, в том числе не поддерживается библиотеками Си (приложение К относится к опциональным возможностям).
URL: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
Новость: http://www.opennet.me/opennews/art.shtml?num=43062
Этот чудософт удивляет. То они поносят Си как могут, то свои фичи туда пытаются запилить. Какие-то непоследовательные.
вы так говорите, как будто завязывание на VS с С++
и пропаганда C# - вещи которые мешают друг другу
> Этот чудософт удивляет. То они поносят Си как могут, то свои фичи
> туда пытаются запилить. Какие-то непоследовательные.Вполне последовательные -- как по ссылке и пишут:
---
[...] of a "sponsor" that has no interest in actually implementing the standard
and who has done nothing but try to undermine the C language for the past 20+ years
--- https://sourceware.org/ml/libc-alpha/2014-08/msg00151.htmlTypical Microsoft (c)
Скорее redhat удивляет, пусть предложат альтернативу хотя бы. Маинтейнеры glibc не хотят добавлять поддержку этих функций, даже когда им предлагают реализацию, а между тем пишут glibc "follows all relevant standards including ISO C11 and POSIX.1-2008". Короче ради того чтобы оставить эту сточку про полную поддержку ISO C11 они и предлагают исключить appendix K из стандарта, лол.
> КорочеНет. Читайте внимательно по ссылке.
Ну что нет? Из предложенных альтернатив там только инструментация и статический анализ, вроде Clang Address Sanitizer, _FORTIFY_SOURCE или Valgrind. API которого можно было бы использовать безопасно в своем коде нет. Используйте ребята ничего, а этот API мы добавлять себе в glibc не будем.В С++ микрософт вроде набросал шаблонов, чтобы пользоваться
char array[10];
strcpy_s(array, "Hello, World");Размер 10 будет автоматом подставлен в шаблонную реализацию strcpy_s, что вообще выглядит шикарно.
Так а что использовать то?
Вот хочу strcpy написать и как теперь best practice?
strncpy, не? У bsd еще strlcpy. Но все это не замена предложенному MS, а замена strcpy.
> У bsd еще strlcpy.Насколько понимаю, ещё в Owl; ну и в альте издавна: http://packages.altlinux.org/ru/4.0/srpms/glibc/patches/glib...
да, альт просто технологический лидер
это аргумент для менеджеров, разве что.
слишком толсто
Зато своё, а не в пиндостане расположенное. Когда начнётся писец по настоящему, и убунта закроет свои репы по санкциям, посмотрю что петь тут будут ))
Ядро линукса и железо x86 разработано в Пиндостане.
Да ты чо, а всё думали что в Linux в Финляндии, а Intel в Ирландии.
>Да ты чо, а всёЖителей сраней-эрзяней это ещё не все, так то!
> У bsd еще strlcpyРазмер выхода за границы буфера на «молчаливое» обрезание строки, которое нужно диагностировать вручную отдельно, и которое в лучшем случае изменит логику работы программы, в худшем — приведёт к не менее серьёзной уязвимости, чем выход за границу буфера. Функции strl*() опасны.
>> У bsd еще strlcpy
> Размер выхода за границы буфера на «молчаливое» обрезание строки, которое нужно
> диагностировать вручную отдельно, и которое в лучшем случае изменит логику работы
> программы, в худшем — приведёт к не менее серьёзной уязвимости, чем
> выход за границу буфера. Функции strl*() опасны.s/Размер/Размен
Так а предлагаемое ещё опасней в некоторых случаях. См. по одной из ссылок про неопределенные runtime-constraints - вообще песня! Оно ещё и "may
cause the program to exit or abort." или просто из-за глобальных переменных/состояния может испортить многопоточность. Ни фига себе "решили проблему переполнения".
> которое нужно диагностировать вручную отдельноИменно так в Си и должно быть. Чтобы быть уверенным, что код делает только то, что ты хочешь, а не то, что хотят компиляторо-/библиотекостроители. В противном случае, пишите на С++ или Питоне.
best practice это использовать например µstr http://www.and.org/ustr/
Костыли и велосипеды
Костыли и велосипеды - это реализация строк на Си.
> Костыли и велосипеды - это реализация строк на Си.Люто, бешено плюсую... В мой юный студенческий мозг в своё время никак не помещалось, что это за именование и разыменование. Учитывая отсутствие инета кроме модемного у богатых ребят, понять и принять это было сложно после Паскаля и Делфи. Хотя даже на прологе строки пишутся тупо в кавычках. Да и во многих других языках.
> Хотя даже на прологе строки пишутся тупо в кавычках. Да и во многих других языках."Даже" намекает, что в Си, якобы, так нельзя?
>понять и принять это было сложно после Паскаляхреново ты знал паскаль
Те, кто использует Си в качестве языка обработки текста, должны страдать.
> реализация строк
> в качестве языка обработки текстахорошо натянул.
Git?
Страдай, я разрешаю
snprintf
Медленно!
Что можно ожидать от конторы, в которой указатели прячут в макросы.
> Что можно ожидать от конторы, в которой https://ru.wikipedia.org/wiki/Embrace%2C_Extend%2C...Не благодари. :l
>> Что можно ожидать от конторы, в которой https://ru.wikipedia.org/wiki/Embrace%2C_Extend%2C...
> Не благодари. :lЧестно они мне напоминают, рукожопых что ли. Нокия вроде норм мобилки были, но эмэсовские какое-то обыденное и тривиальное, нет особого желания пользоваться. Вот наверняка AOL месседжер был нормальным, а эмэсовским никогда не пользовался, и всегда его отключал удалял и вообще..
А pdf читалка в 8-ке есть своя...
Шизофазия.
Микрософт - это как царь Мидас наоборот. Все к чему он прикасается, превращается в безжизненное, посредственное, ненужное, безысходное говно.
Нокия была прекрасной компанией. Подотстала одно время, увлекшись симбианом, но N900 и N9 (вернее даже, может быть, ветыь развития Maemo-MeeGo) были вещами прорывными, и при должной поддержке платформы у нас бы на мобильном рынке было не два игрока, а три. А потом пришел Микрософт.
Вон скупе - когда-то даже p2p был.
У вас хронология события нарушена.Motorola, Nokia и Blackberry, получив некую популярность, растеряли её, докатились до предбанкротного состояния и искали кому продаться.
Параллельно Google и Microsoft искали способ войти на рынок мобильной аппаратуры.
Motorola продалась Google. Nokia - MS.
Blackberry до сих пор тихо подыхает. И в ближайшие несколько лет, видимо, будет кем-нибудь поглощена.
МС и Google не заинтересованы в производстве мобильных телефонов, им нужны патенты и технологии чтобы не профукать приближающийся (по прогнозам аналитиков) интернет вещей, который должен расти по 20-50% в год.
Второй прорывной технологией ближайшего будущего должен стать автомобиль без водителя. Все крупнейшие компании (как ИТ, так и автомобильные) уже имеют свои прототипы. А кто не имеет, будут покупать чужие убыточные бизнесы.
Ничего личного, только бизнес.
> Motorola продалась Google. Nokia - MS.Когда доведётся копать за еду, так и скажете -- "взял Элопа на работу".
И не спрашивайте, за что это. За вот это.
> А pdf читалка в 8-ке есть своя...Офигенная вещь! Как раз недавно мозг попарила!
Есть у меня одна маленькая, несложная и довольно древняя программка. Суть её работы тут особо не важна, но она умеет, в качестве результата, формировать, скажем так, некие отчеты-таблицы в pdf-формате. Зависимостей минимум, от ОС не зависит.
И тут мне звонят и говорят, что данные ошибочные получаются в таблицах... Я пришел, а там как раз 8-ка. От ОС функционал вообще не зависит, поэтому значения сначала не придал.
Всяко думал что в программе баг какой или в данных лажа... Смотрю-смотрю, а ошибки не нахожу. И данные в порядке и логика вроде без ошибок и таблички переформировывал несколько раз. Открыл pdf-ничек другой смотрелкой (не сразу сообразил), глядь, а там всё правильно! Открыл снова во встроенной (тот же файл!) - лажа. Он, сука, где-то закешировал что-то и раз за разом показывал старое содержимое, несмотря на то что файл был несколько раз уже изменен на нормальный! Через какое-то время его кеш "протух", он перечитал, наконец, файл который в нем и пытались открыть и стал тоже показывать нормально. Не скажу, конечно, чтоб я был особо удивлен - вендор приучил, но уж от смотрелки pdf подлянки все-таки не ожидал.
Имейте ввиду, если кому-то доведется пытаться разобраться в проблеме, симптомом которой является "неправильные данные в pdf в 8-ке". А ещё лучше - stay away, если есть возможность.
вот так кулстори!
Интереснее было бы послушать про реализацию multi-threaded части стандарта C11. Судя по спекам - в C11 появляются thread locals. Значит ли это, что многопоточность в стиле msvcrt.dll окончательно победила и обязательна к исполнению в любом компиляторе (например, в каждом потоке свой буфер под результат ctime и т.д.)? Или в POSIX придется продолжать использовать reentrant-функции?Еще была инфа, что реализация потоков в стиле C11 сильно конфликтует с pthreads. В какую сторону будут двигаться новые стандарты POSIX? По их логике - если есть конфликт со спецификацией компилятора C - все противоречия трактуются в пользу стандарта на компилятор. Но C11 что-то не очень спешит появляться в *nix...
> логике - если есть конфликт со спецификацией компилятора C - все
> противоречия трактуются в пользу стандарта на компилятор. Но C11 что-то не
> очень спешит появляться в *nix...Нудк, напишут ещё новость, мол, спонсированный Майкрософтом необязательный к исполнению стандарт C11 решено по..рить для совместимости с сущ.реализациями.
Начало же уже положено!
>В итоге, недоработки архитектуры данного механизма и проблемы, всплывшие при попытках создания практических реализаций, привели к тому, что данный интерфейс на практике нигде не реализован и не применяетсяпочитал оригинальный тред. Насчет отсутствия реализаций - вранье (как минимум есть MSVC), насчет невозможности писать thread-safe-код - снова вранье. Откуда следует неизбежный вывод: у товарища просто бомбануло от того что эта часть стандарта предложена "корпорацией зла" (тм). Предлагаю ему переключиться на C++ и начать там бороться за отмену оператора new и кастомных аллокаторов.
>насчет невозможности писать thread-safe-код - снова враньеНу давай, расскажи нам, как писать thread-safe код с глобальными переменными.
https://code.google.com/p/slibc/
хорошо что какой-нибудь _fastcall __dllcall не втиснули
> оператора new и кастомных аллокаторов.а причём тут microsoft?
> Насчет отсутствия реализаций - вранье (как минимум есть MSVC)А теперь давай вместе почитаем что же там в действительности написано:
Despite the specification of the APIs having been around for over a decade only a handful of implementations exist with varying degrees of completeness and conformance.
Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1.
А теперь выдели из написанного доказанные утверждения и личное мнение автора. Внимание следует обращать лишь на первое.Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.
> Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.Чей компилятор/VS в 2011 году не поддерживал с99? Типа, классическое опеннетное "мы не пользуемся, но лучше знаем, как надо ПРАВИЛЬНО!"? )
> Пока что я вижу лишь желание исключить модуль только потому,
> что он предложен конкретной компанией.s/предложен/подложен/
> Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.Даже если это так - я лично поддерживаю всеми руками и ногами чтобы исключали и запрещали все что предлагают Майкрософт, Эппл и еще ряд зажравшихся и обнаглевших компании.
> Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.Зенки протри. Или к окулисту сходи. Ну на самом деле: твои проблемы со зрением -- это *твои* проблемы. Не надо с ними приставать к прохожим, держи их при себе. Или иди к специалисту.
> предложен конкретной компаниейчья "implementation is incomplete". Это примерно как с OpenXML.
Все эти _s функции, на самом деле мертвому припарок, всегда им были им же и останутся! Они не добавляют защищенности, они добавляют кучу лишнего кода. Как минимум, они добавляют кучу проверок, которые можно сделать, не меняя синтаксис стандартных функций, вполне самостоятельно. Ради интереса попробуйте перенести любую С-программу в их студию и переделать на _s. Там с ума сойти сколько переписывать, смысла нет. Так эти наглецы еще и показывают предупреждения и ошибки нагло навязывая использовать эти ненужные _s. Чтобы переключиться на нормальное поведение? там какую-то еще коyстанту надо пропихнуть компилятору, чтобы он прекратил этот кошмар!Непонятно, почему это вообще впихнули в стандарт, благо, это лишь необязательное приложение.
Особенно феерично смотрятся _s-версии функций, которые и так принимают размер целевого буфера (например, snprintf). Казалось бы, если уже есть параметр, позволяющий избежать переполнение буфера, зачем добавлять ещё один с точно такой же целью? Но Microsoft была бы не Microsoft, если бы действовала согласно здравому смыслу...
> Особенно феерично смотрятся _s-версии функций, которые и так принимают размер целевого
> буфера (например, snprintf). Казалось бы, если уже есть параметр, позволяющий избежать
> переполнение буфера, зачем добавлять ещё один с точно такой же целью?Так в новых функциях есть ещё некий умолчальный обработчик runtime-constraints, который по стандарту(!): "The behavior of the default handler is implementation-defined, and it may
cause the program to exit or abort." Не отказаться выполнять небезопасное действие, не вернуть ошибку, а имеет законное право обрушить программу! И этот обработчик один на всё! Можно задать свой, но он тоже будет один на все вызовы (из всех используемых библиотек и потоков)! Какой уж тут здравый смысл...