The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Разработанное в Microsoft приложение "K" предложено к удалению из стандарта C11

30.09.2015 03:42

Компания Red Hat инициировала процесс удаления приложения "K" в следующей версии стандарта языка Си. Приложение K было добавлено в нынешний стандарт C11 и включает разработанный компанией Microsoft набор функций "*_s" с интерфейсом для проверки границ буферов. Проблема состоит в том, что данный интерфейс был добавлен в стандарт под давлением "спонсора" без предварительной проверки на практике.

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

  1. Главная ссылка к новости (http://www.open-std.org/jtc1/s...)
  2. OpenNews: Опубликован новый международный стандарт для языка Си (C1X/C11)
  3. OpenNews: Спецификация C++0X принята в качестве международного стандарта C++11
  4. OpenNews: В Clang доведена до готовности поддержка стандарта C++11 и приняты патчи для пересборки ядра Linux
  5. OpenNews: Обзор предложений для включения в состав стандарта C++14
Лицензия: CC-BY
Тип: Тема для размышления
Короткая ссылка: https://opennet.ru/43062-c11
Ключевые слова: c11
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 08:38, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Этот чудософт удивляет. То они поносят Си как могут, то свои фичи туда пытаются запилить. Какие-то непоследовательные.
     
     
  • 2.2, x0r (??), 08:47, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +7 +/
    вы так говорите, как будто завязывание на VS с С++
    и пропаганда C# - вещи которые мешают друг другу
     
  • 2.5, Michael Shigorin (ok), 09:17, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +17 +/
    > Этот чудософт удивляет. То они поносят Си как могут, то свои фичи
    > туда пытаются запилить. Какие-то непоследовательные.

    Вполне последовательные -- как по ссылке и пишут:

    ---
    [...] 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.html

    Typical Microsoft (c)

     
  • 2.60, Джо (?), 09:33, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Скорее redhat удивляет, пусть предложат альтернативу хотя бы. Маинтейнеры glibc не хотят добавлять поддержку этих функций, даже когда им предлагают реализацию, а между тем пишут glibc "follows all relevant standards including ISO C11 and POSIX.1-2008". Короче ради того чтобы оставить эту сточку про полную поддержку ISO C11 они и предлагают исключить appendix K из стандарта, лол.
     
     
  • 3.61, Michael Shigorin (ok), 12:35, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Короче

    Нет.  Читайте внимательно по ссылке.

     
     
  • 4.62, Джо (?), 16:16, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну что нет? Из предложенных альтернатив там только инструментация и статический анализ, вроде Clang Address Sanitizer, _FORTIFY_SOURCE или Valgrind. API которого можно было бы использовать безопасно в своем коде нет. Используйте ребята ничего, а этот API мы добавлять себе в glibc не будем.

    В С++ микрософт вроде набросал шаблонов, чтобы пользоваться

    char array[10];
    strcpy_s(array, "Hello, World");

    Размер 10 будет автоматом подставлен в шаблонную реализацию strcpy_s, что вообще выглядит шикарно.

     

  • 1.3, iPony (?), 08:58, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Так а что использовать то?
    Вот хочу strcpy написать и как теперь best practice?
     
     
  • 2.4, anon4ik (?), 09:02, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +7 +/
    strncpy, не? У bsd еще strlcpy. Но все это не замена предложенному MS, а замена strcpy.
     
     
  • 3.7, Michael Shigorin (ok), 09:20, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > У bsd еще strlcpy.

    Насколько понимаю, ещё в Owl; ну и в альте издавна: http://packages.altlinux.org/ru/4.0/srpms/glibc/patches/glibc-2.5-obsd-alt-st

     
     
  • 4.24, qwert (??), 13:11, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    да, альт просто технологический лидер
     
     
  • 5.27, chinarulezzz (ok), 14:50, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это аргумент для менеджеров, разве что.
     
  • 5.35, Аноним (-), 17:38, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    слишком толсто
     
  • 5.51, count0krsk (ok), 15:04, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зато своё, а не в пиндостане расположенное. Когда начнётся писец по настоящему, и убунта закроет свои репы по санкциям, посмотрю что петь тут будут ))
     
     
  • 6.56, Аноним (-), 23:17, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ядро линукса и железо x86 разработано в Пиндостане.
     
     
  • 7.58, pavlinux (ok), 01:46, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ты чо, а всё думали что в Linux в Финляндии, а Intel в Ирландии.  
     
     
  • 8.66, Яро Ш. Я. (?), 22:23, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Жителей сраней-эрзяней это ещё не все, так то ... текст свёрнут, показать
     
  • 3.10, Аноним (-), 09:39, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > У bsd еще strlcpy

    Размер выхода за границы буфера на «молчаливое» обрезание строки, которое нужно диагностировать вручную отдельно, и которое в лучшем случае изменит логику работы программы, в худшем — приведёт к не менее серьёзной уязвимости, чем выход за границу буфера. Функции strl*() опасны.

     
     
  • 4.11, Аноним (-), 09:39, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> У bsd еще strlcpy
    > Размер выхода за границы буфера на «молчаливое» обрезание строки, которое нужно
    > диагностировать вручную отдельно, и которое в лучшем случае изменит логику работы
    > программы, в худшем — приведёт к не менее серьёзной уязвимости, чем
    > выход за границу буфера. Функции strl*() опасны.

    s/Размер/Размен

     
  • 4.45, Ytch (ok), 00:26, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так а предлагаемое ещё опасней в некоторых случаях. См. по одной из ссылок про неопределенные runtime-constraints - вообще песня! Оно ещё и "may
    cause the program to exit or abort." или просто из-за глобальных переменных/состояния может испортить многопоточность. Ни фига себе "решили проблему переполнения".
     
  • 4.50, dq0s4y71 (??), 14:31, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > которое нужно диагностировать вручную отдельно

    Именно так в Си и должно быть. Чтобы быть уверенным, что код делает только то, что ты хочешь, а не то, что хотят компиляторо-/библиотекостроители. В противном случае, пишите на С++ или Питоне.

     
  • 2.6, Аноним (-), 09:18, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    best practice это использовать например µstr http://www.and.org/ustr/
     
     
  • 3.8, Аноним (-), 09:24, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Костыли и велосипеды
     
     
  • 4.15, chinarulezzz (ok), 11:23, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Костыли и велосипеды - это реализация строк на Си.
     
     
  • 5.52, count0krsk (ok), 15:22, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Костыли и велосипеды - это реализация строк на Си.

    Люто, бешено плюсую... В мой юный студенческий мозг в своё время никак не помещалось, что это за именование и разыменование. Учитывая отсутствие инета кроме модемного у богатых ребят, понять и принять это было сложно после Паскаля и Делфи. Хотя даже на прологе строки пишутся тупо в кавычках. Да и во многих других языках.

     
     
  • 6.59, Ytch (ok), 03:12, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотя даже на прологе строки пишутся тупо в кавычках. Да и во многих других языках.

    "Даже" намекает, что в Си, якобы, так нельзя?

     
  • 6.67, Яро Ш. Я. (?), 22:24, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >понять и принять это было сложно после Паскаля

    хреново ты знал паскаль

     
  • 5.53, dq0s4y71 (??), 16:42, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Те, кто использует Си в качестве языка обработки текста, должны страдать.
     
     
  • 6.54, chinarulezzz (ok), 19:45, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > реализация строк
    > в качестве языка обработки текста

    хорошо натянул.


     
  • 6.55, serg (??), 21:14, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Git?
     
  • 6.68, Яро Ш. Я. (?), 22:25, 02/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Страдай, я разрешаю
     
  • 2.12, Аноним (-), 09:59, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    snprintf
     
     
  • 3.31, Тузя (ok), 16:30, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Медленно!
     

  • 1.9, Анонимус Сапиенс (?), 09:29, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Что можно ожидать от конторы, в которой указатели прячут в макросы.
     
     
  • 2.17, Andrey Mitrofanov (?), 11:31, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Что можно ожидать от конторы, в которой https://ru.wikipedia.org/wiki/Embrace%2C_Extend%2C_and_Extinguish

    Не благодари. :l

     
     
  • 3.23, Аноним (-), 12:33, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что можно ожидать от конторы, в которой https://ru.wikipedia.org/wiki/Embrace%2C_Extend%2C_and_Extinguish
    > Не благодари. :l

    Честно они мне напоминают, рукожопых что ли. Нокия вроде норм мобилки были, но эмэсовские какое-то обыденное и тривиальное, нет особого желания пользоваться.  Вот наверняка AOL месседжер был нормальным, а эмэсовским никогда не пользовался, и всегда его отключал удалял и вообще..
    А pdf читалка в 8-ке есть своя...

     
     
  • 4.33, Аноним (-), 17:10, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Шизофазия.
     
  • 4.36, dr Equivalent (ok), 17:39, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Микрософт - это как царь Мидас наоборот. Все к чему он прикасается, превращается в безжизненное, посредственное, ненужное, безысходное говно.
    Нокия была прекрасной компанией. Подотстала одно время, увлекшись симбианом, но N900 и N9 (вернее даже, может быть, ветыь развития Maemo-MeeGo) были вещами прорывными, и при должной поддержке платформы у нас бы на мобильном рынке было не два игрока, а три. А потом пришел Микрософт.
    Вон скупе - когда-то даже p2p был.
     
     
  • 5.37, клоун (?), 18:30, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У вас хронология события нарушена.

    Motorola, Nokia и Blackberry, получив некую популярность, растеряли её, докатились до предбанкротного состояния и искали кому продаться.

    Параллельно Google и Microsoft искали способ войти на рынок мобильной аппаратуры.

    Motorola продалась Google. Nokia - MS.

    Blackberry до сих пор тихо подыхает. И в ближайшие несколько лет, видимо, будет кем-нибудь поглощена.

    МС и Google не заинтересованы в производстве мобильных телефонов, им нужны патенты и технологии чтобы не профукать приближающийся (по прогнозам аналитиков) интернет вещей, который должен расти по 20-50% в год.

    Второй прорывной технологией ближайшего будущего должен стать автомобиль без водителя. Все крупнейшие компании (как ИТ, так и автомобильные) уже имеют свои прототипы. А кто не имеет, будут покупать чужие убыточные бизнесы.

    Ничего личного, только бизнес.

     
     
  • 6.42, Michael Shigorin (ok), 20:46, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Motorola продалась Google. Nokia - MS.

    Когда доведётся копать за еду, так и скажете -- "взял Элопа на работу".
    И не спрашивайте, за что это.  За вот это.

     
  • 4.46, Ytch (ok), 00:53, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А pdf читалка в 8-ке есть своя...

    Офигенная вещь! Как раз недавно мозг попарила!
    Есть у меня одна маленькая, несложная и довольно древняя программка. Суть её работы тут особо не важна, но она умеет, в качестве результата, формировать, скажем так, некие отчеты-таблицы в pdf-формате. Зависимостей минимум, от ОС не зависит.
    И тут мне звонят и говорят, что данные ошибочные получаются в таблицах... Я пришел, а там как раз 8-ка. От ОС функционал вообще не зависит, поэтому значения сначала не придал.
    Всяко думал что в программе баг какой или в данных лажа... Смотрю-смотрю, а ошибки не нахожу. И данные в порядке и логика вроде без ошибок и таблички переформировывал несколько раз. Открыл pdf-ничек другой смотрелкой (не сразу сообразил), глядь, а там всё правильно! Открыл снова во встроенной (тот же файл!) - лажа. Он, сука, где-то закешировал что-то и раз за разом показывал старое содержимое, несмотря на то что файл был несколько раз уже изменен на нормальный! Через какое-то время его кеш "протух", он перечитал, наконец, файл который в нем и пытались открыть и стал тоже показывать нормально. Не скажу, конечно, чтоб я был особо удивлен - вендор приучил, но уж от смотрелки pdf подлянки все-таки не ожидал.
    Имейте ввиду, если кому-то доведется пытаться разобраться в проблеме, симптомом которой является "неправильные данные в pdf в 8-ке". А ещё лучше - stay away, если есть возможность.

     
     
  • 5.57, fox_mulder (?), 23:59, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вот так кулстори!
     

  • 1.13, Аноним (-), 10:18, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интереснее было бы послушать про реализацию multi-threaded части стандарта C11. Судя по спекам - в C11 появляются thread locals. Значит ли это, что многопоточность в стиле msvcrt.dll окончательно победила и обязательна к исполнению в любом компиляторе (например, в каждом потоке свой буфер под результат ctime и т.д.)? Или в POSIX придется продолжать использовать reentrant-функции?

    Еще была инфа, что реализация потоков в стиле C11 сильно конфликтует с pthreads. В какую сторону будут двигаться новые стандарты POSIX? По их логике - если есть конфликт со спецификацией компилятора C - все противоречия трактуются в пользу стандарта на компилятор. Но C11 что-то не очень спешит появляться в *nix...

     
     
  • 2.18, Andrey Mitrofanov (?), 11:42, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > логике - если есть конфликт со спецификацией компилятора C - все
    > противоречия трактуются в пользу стандарта на компилятор. Но C11 что-то не
    > очень спешит появляться в *nix...

    Нудк, напишут ещё новость, мол, спонсированный Майкрософтом необязательный к исполнению стандарт C11 решено по..рить для совместимости с сущ.реализациями.

    Начало же уже положено!

     

  • 1.14, Аноним (-), 11:21, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    >В итоге, недоработки архитектуры данного механизма и проблемы, всплывшие при попытках создания практических реализаций, привели к тому, что данный интерфейс на практике нигде не реализован и не применяется

    почитал оригинальный тред. Насчет отсутствия реализаций - вранье (как минимум есть MSVC), насчет невозможности писать thread-safe-код - снова вранье. Откуда следует неизбежный вывод: у товарища просто бомбануло от того что эта часть стандарта предложена "корпорацией зла" (тм). Предлагаю ему переключиться на C++ и начать там бороться за отмену оператора new и кастомных аллокаторов.

     
     
  • 2.19, Аноним (-), 11:43, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >насчет невозможности писать thread-safe-код - снова вранье

    Ну давай, расскажи нам, как писать thread-safe код с глобальными переменными.

     
     
  • 3.25, Аноним (-), 13:19, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://code.google.com/p/slibc/
     
  • 2.20, Вареник (?), 11:51, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    хорошо что какой-нибудь _fastcall __dllcall не втиснули
     
  • 2.21, Аноним (-), 12:11, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > оператора new и кастомных аллокаторов.

    а причём тут microsoft?

     
  • 2.22, Аноним (-), 12:32, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Насчет отсутствия реализаций - вранье (как минимум есть 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.

     
     
  • 3.26, клоун (?), 14:04, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • –5 +/
    А теперь выдели из написанного доказанные утверждения и личное мнение автора. Внимание следует обращать лишь на первое.

    Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.

     
     
  • 4.29, Нимано (?), 16:10, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.

    Чей компилятор/VS в 2011 году не поддерживал с99? Типа, классическое опеннетное "мы не пользуемся, но лучше знаем, как надо ПРАВИЛЬНО!"? )

     
  • 4.32, Michael Shigorin (ok), 17:06, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока что я вижу лишь желание исключить модуль только потому,
    > что он предложен конкретной компанией.

    s/предложен/подложен/

     
  • 4.43, Аноним (-), 21:38, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.

    Даже если это так - я лично поддерживаю всеми руками и ногами чтобы исключали и запрещали все что предлагают Майкрософт, Эппл и еще ряд зажравшихся и обнаглевших компании.

     
  • 4.48, Ordu (ok), 11:23, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока что я вижу лишь желание исключить модуль только потому, что он предложен конкретной компанией.

    Зенки протри. Или к окулисту сходи. Ну на самом деле: твои проблемы со зрением -- это *твои* проблемы. Не надо с ними приставать к прохожим, держи их при себе. Или иди к специалисту.

     

  • 1.28, Аноним (-), 15:10, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > предложен конкретной компанией

    чья "implementation is incomplete". Это примерно как с OpenXML.

     
  • 1.34, Тузя (ok), 17:17, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Все эти _s функции, на самом деле мертвому припарок, всегда им были им же и останутся! Они не добавляют защищенности, они добавляют кучу лишнего кода. Как минимум, они добавляют кучу проверок, которые можно сделать, не меняя синтаксис стандартных функций, вполне самостоятельно. Ради интереса попробуйте перенести любую С-программу в их студию и переделать на _s. Там с ума сойти сколько переписывать, смысла нет. Так эти наглецы еще и показывают предупреждения и ошибки нагло навязывая использовать эти ненужные _s. Чтобы переключиться на нормальное поведение? там какую-то еще коyстанту надо пропихнуть компилятору, чтобы он прекратил этот кошмар!

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

     
     
  • 2.44, Аноним (-), 23:31, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Особенно феерично смотрятся _s-версии функций, которые и так принимают размер целевого буфера (например, snprintf). Казалось бы, если уже есть параметр, позволяющий избежать переполнение буфера, зачем добавлять ещё один с точно такой же целью? Но Microsoft была бы не Microsoft, если бы действовала согласно здравому смыслу...
     
     
  • 3.47, Ytch (ok), 01:17, 01/10/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Особенно феерично смотрятся _s-версии функций, которые и так принимают размер целевого
    > буфера (например, snprintf). Казалось бы, если уже есть параметр, позволяющий избежать
    > переполнение буфера, зачем добавлять ещё один с точно такой же целью?

    Так в новых функциях есть ещё некий умолчальный обработчик runtime-constraints, который по стандарту(!): "The behavior of the default handler is implementation-defined, and it may
    cause the program to exit or abort." Не отказаться выполнять небезопасное действие, не вернуть ошибку, а имеет законное право обрушить программу! И этот обработчик один на всё! Можно задать свой, но он тоже будет один на все вызовы (из всех используемых библиотек и потоков)! Какой уж тут здравый смысл...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру