Вы используете TR 24731 'безопасные' функции? [закрытый]

Прямой ответ на вопрос

мне нравится ответ Robert, но у меня также есть некоторые представления о вопросах, которые я поднял.

• Вы пользуетесь библиотекой или компилятором с поддержкой функций TR24731-1?

  нет, я не делаю.

• , Если так, который компилятор или библиотека и на который платформа (платформы)?

  я полагаю, что функции обеспечиваются Visual Studio MS (VC MS ++ Выпуск 2008 года, например), и существуют предупреждения поощрить Вас использовать их.

• Вы раскрывали какие-либо ошибки в результате фиксации Вашего кода для использования этих функций?

  Еще. И я не ожидаю раскрывать многих в своем коде. Часть другого кода я работаю с - возможно. Но я должен все же быть убежден.

• , Какие функции обеспечивают большую часть значения?

  мне нравится то, что printf_s () семья функций не принимают' %n' спецификатор формата.

• там кто-либо, которые не обеспечивают значения или отрицательной величины?

  tmpfile_s() и tmpnam_s() функции являются ужасным разочарованием. Они действительно должны были работать больше как [1 110], который и создает файл и открывает его, чтобы гарантировать, что нет никакого TOCTOU (время проверки, время использования) уязвимости. В настоящий момент те два обеспечивают очень мало значения.

  я также думаю, что strerrorlen_s() обеспечивает очень мало значения.

• Вы планируете пользоваться библиотекой в будущем?

  я колеблюсь об этом. Я запустил работу над библиотекой, которая реализует возможности TR 24731 по стандартной библиотеке для C, но была поймана объемом поблочного тестирования, должен был продемонстрировать, что это работает правильно. Я не уверен, продолжить ли это. У меня есть некоторый код, который я хочу портировать на Windows (главным образом из извращенного требования оказать поддержку на всех платформах - это работало над производными Unix в течение нескольких десятилетий теперь). К сожалению, чтобы заставить его компилировать без предупреждений из компиляторов MSVC, я должен оштукатурить код с материалом для предотвращения MSVC, болтающего обо мне использующий совершенно надежное (когда тщательно используется) функции стандартной библиотеки для C. И это не вызывает аппетит. Это достаточно плохо, что я должен иметь дело с большей частью из ценности двух десятилетий системы, которая разработала за тот период; необходимость иметь дело с чьей-то идеей забавы (то, чтобы заставлять людей принять TR 24731, когда им не нужно к) является раздражающей. Это было частично, почему я запустил разработку библиотеки - чтобы позволить мне использовать те же интерфейсы на Unix и Windows. Но я не уверен, что я сделаю отсюда.

• Вы отслеживаете работу TR24731-2 вообще?

  я не отслеживал его, пока я не перешел к сайту стандартов при сборе данных для вопроса. asprintf() и vasprintf() функции, вероятно, ценны; я использовал бы тех. Я не уверен в потоковых функциях ввода-вывода памяти. Стандартизация strdup() на уровне C была бы огромным шагом вперед. Это кажется менее спорным мне, чем часть 1 (проверка границ) интерфейсы.

В целом, я не убежден частью 1 'Проверяющие Границы Интерфейсы. Материал в проекте части 2 'Динамические Функции Выделения лучше.

, Если бы это было мое дело, я переместился бы несколько вроде части 1, но я также пересмотрел интерфейсы в стандартной библиотеке для C C99, которые возвращаются char * к запуску строки (например, strcpy() и strcat()) так, чтобы вместо того, чтобы возвратить указатель на запуск, они возвратили бы указатель на пустой байт в конце новой строки. Это сделало бы некоторые общие идиомы (такие как повторная конкатенация строк на конец другого) более эффективными, потому что это сделает его тривиальным для предотвращения квадратичного поведения, показанного кодом, который неоднократно использует strcat(). Замены все гарантировали бы, чтобы пустое завершение выходных строк, как версии TR24731 сделали. Я не совершенно против идеи интерфейса проверки, ни к функциям обработки исключений. Это - хитрый бизнес.

реализация Microsoft не является тем же как стандартной спецификацией

<глоток> , Обновление (2011-05-08)

Видит также этот вопрос . К сожалению, и фатально к полноценности функций TR24731, определения некоторых функций отличаются между реализацией Microsoft и стандартом, представляя их бесполезный (мне). Мой ответ там цитирует vsnprintf_s().

, Например, TR 24731-1 говорит, что интерфейс к [1 120]:

#define __STDC_WANT_LIB_EXT1__ 1
#include <stdarg.h>
#include <stdio.h>
int vsnprintf_s(char * restrict s, rsize_t n,
                const char * restrict format, va_list arg);

, К сожалению, MSDN говорит, что интерфейс к [1 121]:

int vsnprintf_s(
   char *buffer,
   size_t sizeOfBuffer,
   size_t count,
   const char *format,
   va_list argptr 
);

Параметры

• буфер - Место хранения для вывода.
• sizeOfBuffer - размер буфера для вывода.
• количество - Максимальное количество символов для записи (не включая завершающийся пустой указатель), или _TRUNCATE.
• формат - спецификация Формата.
• argptr - Указатель на список аргументов.

Примечание, что это не просто вопрос отображения типа: количество фиксированных аргументов отличается, и поэтому противоречиво. Это также неясно мне (и по-видимому в комитет по стандартам также) что преимущество, там к наличию и 'sizeOfBuffer' и 'количество'; это похоже на ту же информацию дважды (или, по крайней мере, код будет обычно писаться с тем же значением для обоих параметров).

Точно так же существуют также проблемы с [1 122] и его родственники. Microsoft говорит, что тип параметра длины буфера unsigned (явно утверждение 'Параметра размера имеет тип unsigned, не size_t'). Напротив, в Приложении K параметр размера имеет тип rsize_t, который является ограниченным вариантом [1 127] (rsize_t, другое название [1 129], но RSIZE_MAX меньше, чем [1 131]). Так, снова, код, звоня scanf_s() должен был бы быть записан по-другому для Microsoft C и Стандарта C.

Первоначально, я планировал использовать 'безопасные' функции в качестве способа заставить некоторый код компилировать чисто в Windows, а также Unix, не будучи должен записать условный код. Так как это побеждено, потому что Microsoft и функции ISO являются не всегда тем же, это - в значительной степени время для отказа.

Изменения в Microsoft vsnprintf() в Visual Studio 2015

В документации Visual Studio 2015 года для [1 154] vsnprintf() , это отмечает, что интерфейс изменился:

Однако интерфейс Microsoft для [1 155] vsnprintf_s() не изменился.

struct tm *localtime_s(const time_t * restrict timer,
                       struct tm * restrict result);

по сравнению с вариантом MSDN [1 156] localtime_s() определенный как:

errno_t localtime_s(struct tm* _tm, const time_t *time);

и вариант POSIX localtime_r() определенный как:

struct tm *localtime_r(const time_t *restrict timer,
                       struct tm *restrict result);

стандарт C11 и функции POSIX эквивалентны кроме имени. Функция Microsoft отличается в интерфейсе даже при том, что это совместно использует имя со стандартом C11.

Другой пример различий Microsoft strtok_s() и K Приложения strtok_s():

char *strtok_s(char *strToken, const char *strDelimit, char **context); 

по сравнению с:

char *strtok_s(char * restrict s1, rsize_t * restrict s1max, const char * restrict s2, char ** restrict ptr);

Примечание, что вариант Microsoft имеет 3 аргумента, тогда как вариант Приложения K имеет 4. Это означает, что список аргументов к Microsoft strtok_s() совместим с POSIX strtok_r() , — так звонит в них, являются эффективно взаимозаменяемыми, если Вы меняете имя функции (например, макросом) —, но Стандарт C (Приложение K) версия отличается от обоих с дополнительным аргументом.

вопрос Различные объявления [1 147] на Mac и Linux имеют ответ, который также обсуждает qsort_s(), как определено Microsoft и qsort_s(), как определено TR24731-1 — снова, интерфейсы отличаются.

ISO/IEC 9899:2011 — Стандарт C11

стандарт C11 ( Проект декабря 2010; Вы могли когда-то получить копию PDF категорического стандарта, ISO/IEC 9899:2011, из веб-магазина ANSI за 30 долларов США) действительно имеет функции TR24731-1 в нем как дополнительная часть стандарта. Они определяются в Приложении K (проверяющие Границы Интерфейсы), который является 'нормативным', а не 'информационным', но это является дополнительным.

стандарт C11 не имеет функций TR24731-2 в нем —, который печален, потому что эти vasprintf() функция и ее родственники могли быть действительно полезными.

Быстрая сводка:

• C11 содержит TR24731-1
• C11, не содержит TR24731-2
• C18, совпадает с C11 w.r.t TR24731.

Предложение удалить Приложение K от преемника C11

Deduplicator, на который указывают в комментарий к другому вопросу, что существует предложение перед комитетом по стандарту ISO C (ISO/IEC JTC1/SC22/WG14)

• полевой N1967 Опыт с Приложением K — Интерфейсы Проверки Границ

, Это содержит ссылки на некоторые существующие реализации функций Приложения K — ни один из них широко используемый (но можно найти их с помощью документа, если Вам интересно).

документ заканчивается рекомендацией:

Поэтому мы предлагаем, чтобы Приложение K было или удалено из следующего пересмотра стандарта C, или удержано от использования и затем удалено.

я поддерживаю ту рекомендацию.

стандарт C18 не изменил состояние Приложения K. Существует статья защита N2336 для внесения некоторых изменений в Приложение K, восстановление его дефектов вместо того, чтобы удалить его в целом.

Используете ли вы библиотеку или компилятор с поддержкой функций TR24731-1? Если да, то какой компилятор или библиотека и на какой платформе (платформах)?

Да, Visual Studio 2005 и 2008 (очевидно, для разработки Win32).

Вы обнаружили какие-либо ошибки в результате исправления кода для использования этих функций?

Вроде .... Я написал свою собственную библиотеку безопасных функций (всего около 15, которые мы часто используем), которые будут использоваться на нескольких платформах - Linux, Windows, VxWorks, INtime, RTX и uItron. Причины создания безопасных функций:

• Мы столкнулись с большим количеством ошибок из-за неправильного использования стандартных функций C.
• Меня не удовлетворила информация, переданная в функции TR или возвращенная из них, или в некоторых случаях, их альтернативы POSIX.

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

Какие функции предоставляют наибольшую ценность?

Более безопасные версии vsnprintf, strncpy, strncat.

Есть ли какие-либо версии, которые не предоставляют значения или отрицательное значение?

fopen_s и подобные функции не представляют для меня особой ценности. Я в порядке, если fopen возвращает NULL. Вы всегда должны проверять возвращаемое значение функции. Если кто-то игнорирует возвращаемое значение fopen, что заставит его проверить возвращаемое значение fopen_s? Я понимаю, что fopen_s вернет более конкретную информацию об ошибке, которая может быть полезна в некоторых случаях. Но для того, над чем я работаю, это не имеет значения.

Планируете ли вы использовать библиотеку в будущем?

Мы используем ее сейчас - внутри нашей собственной «безопасной» библиотеки.

Вы вообще отслеживаете работу TR24731-2?

Нет.

Есть ли такие, которые не дают значения или отрицательного значения?

fopen_s и подобные функции не представляют для меня особой ценности. Я в порядке, если fopen возвращает NULL. Вы всегда должны проверять возвращаемое значение функции. Если кто-то игнорирует возвращаемое значение fopen, что заставит его проверить возвращаемое значение fopen_s? Я понимаю, что fopen_s вернет более конкретную информацию об ошибке, которая может быть полезна в некоторых случаях. Но для того, над чем я работаю, это не имеет значения.

Планируете ли вы использовать библиотеку в будущем?

Мы используем ее сейчас - внутри нашей собственной «безопасной» библиотеки.

Вы вообще отслеживаете работу TR24731-2?

Нет.

Есть ли такие, которые не дают значения или отрицательного значения?

fopen_s и подобные функции не представляют для меня особой ценности. Я в порядке, если fopen возвращает NULL. Вы всегда должны проверять возвращаемое значение функции. Если кто-то игнорирует возвращаемое значение fopen, что заставит его проверить возвращаемое значение fopen_s? Я понимаю, что fopen_s вернет более конкретную информацию об ошибке, которая может быть полезна в некоторых случаях. Но для того, над чем я работаю, это не имеет значения.

Планируете ли вы использовать библиотеку в будущем?

Мы используем ее сейчас - внутри нашей собственной «безопасной» библиотеки.

Вы вообще отслеживаете работу TR24731-2?

Нет.

Планируете ли вы использовать библиотеку в будущем?

Мы используем ее сейчас - внутри нашей собственной «безопасной» библиотеки.

Вы вообще отслеживаете работу TR24731-2?

Нет.

Планируете ли вы использовать библиотеку в будущем?

Мы используем ее сейчас - внутри нашей собственной «безопасной» библиотеки.

Вы вообще отслеживаете работу TR24731-2?

Нет.