source

TR 24731 '안전' 기능을 사용합니까?

manysource 2023. 1. 17. 21:20

TR 24731 '안전' 기능을 사용합니까?

ISO C 위원회(ISO/IEC JTC1/SC21/WG14)는 TR 24731-1을 발표하고 TR 24731-2에 대해 작업 중입니다.

TR 24731-1: C 라이브러리 확장 파트 I: 경계 확인 인터페이스

WG14는 보다 안전한 C 라이브러리 기능에 관한 TR 작업을 하고 있습니다.이 TR은 기존 프로그램을 수정하는 것을 목적으로 하며, 종종 버퍼 길이로 추가 매개변수를 추가합니다.최신 초안은 문서 N1225에 있습니다.근거는 문서 N1173에 있습니다.이는 기술 보고서 유형 2가 됩니다.

TR 24731-2: C 라이브러리 확장 - Part II: 동적 할당 함수

WG14는 보다 안전한 C 라이브러리 기능에 관한 TR 작업을 하고 있습니다.이 TR은 버퍼 길이에 대한 추가 매개 변수 대신 동적 할당을 사용하여 새로운 프로그램을 지향합니다.최신 초안은 문서 N1337에 있습니다.이는 기술 보고서 유형 2가 됩니다.

문의사항

  • TR24731-1 기능을 지원하는 라이브러리 또는 컴파일러를 사용하고 있습니까?
  • 그렇다면 어떤 컴파일러 또는 라이브러리와 플랫폼 상에 있습니까?
  • 이러한 기능을 사용하기 위해 코드를 수정한 결과 버그가 발견되었습니까?
  • 가장 큰 가치를 제공하는 기능은 무엇입니까?
  • 가치도 마이너스도 없는 것이 있습니까?
  • 당신은 앞으로 도서관을 이용할 계획입니까?
  • TR24731-2 작업을 추적하고 있습니까?

저는 이 TR의 시작부터(단일 TR일 때) 목소리를 높여 비판해 왔고, 제 소프트웨어에서는 절대 사용하지 않을 것입니다.그들은 원인에 대처하는 것이 아니라 증상을 감추고 있습니다.또한 같은 목표를 훨씬 더 효과적으로 달성할 수 있는 기존의 관행을 촉진하는 것이 아니라 잘못된 안전감을 제공하기 때문에 소프트웨어 설계에 부정적인 영향을 미칠 수 있다고 생각합니다.나는 혼자가 아니다. 사실 나는 이러한 TR을 개발하는 위원회 밖에서 하나의 주요 지지자가 있다는 것을 알지 못한다.

저는 glibc를 사용하고 있기 때문에, glibc의 메인 메인터넌스인 Ulrich Drepper가 이 토픽에 대해 말한 것처럼, 이 난센스에 대처할 필요가 없습니다.

제안된 세이프(r) ISO C 라이브러리가 문제를 완전히 해결하지 못했습니다.프로그래머의 삶을 더 힘들게 하자는 제안은 도움이 되지 않을 것이다.하지만 이것이 바로 제안되는 것입니다.그들은 모두 해야 할 일이 더 많거나 그저 어리석다.

그는 제안된 함수의 여러 가지 문제에 대해 자세히 설명하고 있으며, 다른 곳에서는 glibc가 이를 지원하지 않을 것이라고 지적했습니다.

Austin Group(POSIX 유지보수를 담당)은 TR, 그 코멘트 및 여기에서 입수할 수 있는 위원회의 의견에 대해 매우 비판적인 리뷰를 제공했습니다.오스틴 그룹의 리뷰는 TR에 관한 많은 문제를 상세하게 설명하고 있기 때문에, 여기서 개개의 상세한 것에 대해서는 설명하지 않습니다.

결론부터 말하자면, 저는 이 기능을 지원하거나 지원할 구현을 사용하지 않으며, 이러한 기능을 사용할 계획도 없으며, TR에서 긍정적인 가치를 찾을 수 없습니다.나는 개인적으로 TR이 여전히 어떤 형태로든 살아 있는 유일한 이유는 마이크로소프트가 최근 광범위한 반대에도 불구하고 표준 위원회를 통해 일을 처리할 수 있다는 것을 증명했기 때문이라고 믿는다.만약 이러한 기능이 표준화된다면, 제안서는 몇 년 전부터 존재해 왔으며, 실질적인 커뮤니티의 지지를 얻지 못했기 때문에 널리 이용될 것이라고는 생각하지 않습니다.

질문에 대한 직접적인 답변

로버트의 답변은 마음에 들지만, 제가 제기한 질문들에 대한 의견도 있습니다.

  • TR24731-1 기능을 지원하는 라이브러리 또는 컴파일러를 사용하고 있습니까?

    아니요, 없어요.

  • 그렇다면 어떤 컴파일러 또는 라이브러리와 플랫폼 상에 있습니까?

    이 기능은 MS Visual Studio(예를 들어 MS VC++ 2008 Edition)에서 제공하는 것으로 알고 있으며, 사용을 권장하는 경고가 있습니다.

  • 이러한 기능을 사용하기 위해 코드를 수정한 결과 버그가 발견되었습니까?

    아직은 아니에요.그리고 내 코드의 많은 부분을 밝혀낼 것으로 기대하지 않는다.내가 다루는 다른 코드들 중 일부는 - 아마도.하지만 아직 납득이 가지 않는다.

  • 가장 큰 가치를 제공하는 기능은 무엇입니까?

    printf_s()를 할 수 에 듭니다.%n specificate 지정자.

  • 가치도 마이너스도 없는 것이 있습니까?

    tmpfile_s() ★★★★★★★★★★★★★★★★★」tmpnam_s()기능은 끔찍한 실망입니다.로 더 을 할 가 있었다.mkstemp()둘 다 파일을 생성하여 열어서 TOCTOU(Time-of-Check, Time-of-Use) 취약성이 없는지 확인합니다.을 사용하다

    i i i i i i i i i istrerrorlen_s()는 거의 가치를 제공하지 않습니다.

  • 당신은 앞으로 도서관을 이용할 계획입니까?

    나는 그것에 대해 망설이고 있다.저는 표준 C 라이브러리를 통해 TR 24731의 기능을 구현하는 라이브러리 작업을 시작했지만, 올바르게 동작하고 있음을 증명하기 위해 필요한 유닛 테스트의 양에 걸려 버렸습니다.저는 그것을 계속해야 할지 모르겠어요.Windows에 포팅하고 싶은 코드가 몇 가지 있습니다(주로 모든 플랫폼에서 지원을 제공하고자 하는 비뚤어진 욕구 때문에). Unix 파생 모델에 대해 지난 몇 십 년 동안 작업해 왔습니다).유감스럽게도 MSVC 컴파일러의 경고 없이 컴파일러를 하기 위해서는 완전히 신뢰할 수 있는 표준 C 라이브러리 기능을 사용하여 MSVC가 나에 대해 재잘거리는 것을 방지하기 위해 코드를 석고해야 합니다.그리고 그것은 식욕을 돋우지 않는다.그 기간 동안 발전된 20년치 시스템을 다루어야 한다는 것은 충분히 나쁜 일이다; 누군가의 재미있는 아이디어(필요 없을 때 TR 24731을 채택하게 하는 것)에 대처해야 한다는 것은 짜증나는 일이다.그것이 제가 Unix와 Windows에서 동일한 인터페이스를 사용할 수 있도록 라이브러리 개발을 시작한 이유이기도 합니다.하지만 여기서 뭘 해야 할지 모르겠어요.

  • TR24731-2 작업을 추적하고 있습니까?

    질문 데이터를 수집하면서 표준 사이트에 접속할 때까지 추적하지 않았습니다.asprintf() ★★★★★★★★★★★★★★★★★」vasprintf()을 사용법 저는 그걸 사용하겠어요.메모리 스트림 I/O 기능에 대해서는 잘 모르겠습니다. 있다strdup()C레벨로 표준화하면 큰 진전이 있을 것입니다.이것은 파트 1(바운드체크) 인터페이스보다 논란이 적은 것 같습니다.

전반적으로 파트 1의 "Bounds-Checking Interfaces"에 납득할 수 없습니다.파트 2 '동적 할당 기능' 초안에 있는 자료가 더 낫다.

1의 을 따라 만, C 1의 합니다.char * 「」등).strcpy() ★★★★★★★★★★★★★★★★★」strcat()그러면 포인터를 선두로 되돌리는 대신 새 문자열 끝에 있는 늘바이트로 되돌립니다.를 들어 을 다른의 끝에 하는 등)가은, 「이차 을에 의해서 나타나는 2차 동작을 하는 것이 입니다. 왜냐하면 반복적으로 사용하는 코드에 의해 나타나는 2차 동작을 피하는 것은 사소한 일이기 때문이다.strcat()의 늘 TR24731은 null-termination이다.체크 인터페이스나 예외 처리 기능에 대해 완전히 반대하지는 않습니다.이치노

Microsoft 의 실장은 표준 사양과 다릅니다.

갱신(2011-05-08)

이 질문도 참조해 주세요.안타깝게도 TR24731 함수의 유용성은 Microsoft의 구현과 표준 간에 일부 함수의 정의가 다르기 때문에 사용할 수 없습니다.나의 대답은 다음과 같다.vsnprintf_s().

를 들어, TR 에서는, 「 」, 「TR 24731-1」, 「 」, 「 」에의 됩니다.vsnprintf_s() 말합니다

#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은 인터페이스가vsnprintf_s() 말합니다

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

파라미터

  • buffer - 출력 저장 위치.
  • size Of Buffer - 출력 버퍼 크기.
  • count - 쓸 최대 문자 수(종료 null 제외) 또는 _TRUNCATE.
  • format - 포맷 사양.
  • argptr - 인수 목록을 나타내는 포인터입니다.

이것은 단순히 유형 매핑의 문제가 아닙니다.고정 인수의 수가 다르기 때문에 양립할 수 없습니다.또한 "size Of Buffer"와 "count"를 모두 보유하는 것이 어떤 이점이 있는지 알 수 없습니다. 동일한 정보가 두 번 있는 것처럼 보입니다(또는 적어도 두 파라미터에 대해 동일한 값으로 코드가 작성됩니다).

마찬가지로, 에서의 문제 또한 있습니다.scanf_s()그리고 그 친척들.버퍼 길이 파라미터의 유형은 다음과 같습니다.unsigned입니다'라고되어 있습니다unsigned 아니라, 이에요.size_tK에서는 ')이다 이와는 대조적으로 부록 K에서는 크기 매개변수가 다음과 같다.rsize_tsize_t )rsize_t이에요.size_tRSIZE_MAX 작다SIZE_MAX ) 、 、 시 、 시 、 시 、 드 、 출 ). ). ). ). ). 。scanf_s()Microsoft C standard Standard C microsoft르르 르르 르르 microsoft르 microsoft microsoft 。

원래 저는 조건부 코드를 쓸 필요 없이 Windows와 Unix에서 깔끔하게 컴파일할 수 있는 코드를 얻기 위해 '안전' 기능을 사용할 예정이었습니다.Microsoft 와 ISO 의 기능이 항상 같지는 않기 때문에, 이것은 실패하기 때문에, 거의 포기해도 좋을 때입니다.

® microsoft microsoft 의 변경점에서의 변경vsnprintf() Studio 2015 Visual Studio 2015 ★★★

의 Visual Studio 2015 매뉴얼에는 인터페이스가 변경된 것이 기재되어 있습니다.

및 으로 Visual Studio 2015 windows Windows 10 cr UCRT 작작 beginning beginning beginning beginningvsnprintf는 더 이상 동일하지 않습니다._vsnprintf . 。vsnprintf 기능은 에 준거하고 있습니다.C99는 C99에 준거하고 있습니다._vnsprintf는 하위 호환성을 위해 유지됩니다.

다만, 의 Microsoft 인터페이스는 변경되지 않았습니다.

Microsoft와 Annex K의 다른 예

localtime_s()는 ISOK.2.과 같이되어 있습니다.ISO/IEC 9899:2011 Annex K.3.8.2.4는 다음과 같습니다.

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

의 MSDN 배리언트와의 비교는 다음과 같습니다.

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

및 POSIX 배리언트는 다음과 같이 정의됩니다.

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

C11 표준과 POSIX 함수는 이름과는 동등합니다.Microsoft 의 기능은, C11 규격과 이름이 같으면서도,

또 다른 차이점의 예는 마이크로소프트의strtok_s() Annex의 【Annex K】strtok_s():

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

vs:

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

Microsoft 배리언트에는 3개의 인수가 있는 반면 Annex K 배리언트에는 4개의 인수가 있습니다.의 「」, 「」의 인수 것을 의미합니다.strtok_s()는 POSIX 와 호환성이 있기 때문에 (매크로 등에 의해) 함수명을 변경해도 이들 콜은 효과적으로 교환할 수 있습니다.단, Standard C(Annex K) 버전은 추가 인수와 함께 둘 다와 다릅니다.

"Mac과 Linux에서 선언이 다르다"는 질문에는 다음과 같은 답변이 있습니다.qsort_s() 및 Microsoft에 된 바와 qsort_s()TR24731-1에서 정의한 바와 같이 인터페이스가 다릅니다.

ISO/IEC 9899:2011 - C11 Standard

C11 규격(2010년 12월 초안, 최종 규격인 ISO/IEC 9899:2011의 PDF 카피를 30달러에 ANSI Web 스토어에서 입수 가능)에는, 표준의 옵션의 일부로서 TR24731-1 기능이 포함되어 있습니다.이것들은 Annex K(Bounds-Check Interfaces)에 정의되어 있습니다.이는 '정보'가 아닌 '표준'이지만 옵션입니다.

않습니다.은 C11의 TR24731-2에 의한 것이기 때문에 입니다.【C11】vasprintf()기능 및 그 관련성이 매우 유용할 수 있습니다.

간단한 요약:

  • C11에는 TR24731-1이 탑재되어 있습니다.
  • C11에는 TR24731-2가 포함되어 있지 않습니다.
  • C18은 C11 w.r.t TR24731과 동일합니다.

C11의 후속 버전에서 Annex K를 삭제하는 제안

중복 배제자는 다른 질문에 대한 코멘트에서 ISO C 표준 위원회(ISO/IEC JTC1/SC22/WG14)에 제안서가 있음을 지적했다.

이 문서에는 Annex K 함수의 현존하는 구현에 대한 참조가 포함되어 있습니다.다만, 널리 사용되고 있는 것은 아닙니다(관심이 있는 경우는, 문서를 참조해 주세요).

이 문서의 마지막은 권장 사항입니다.

따라서 우리는 부록 K를 C 표준의 다음 개정판에서 제거하거나 폐지한 후 제거할 것을 제안한다.

저는 그 권고를 지지합니다.

C18 표준은 부록 K의 상태를 변경하지 않았다.Annex K를 일부 수정하고 결함을 완전히 제거하는 것이 아니라 수리하는 것을 옹호하는 N2336이 있습니다.

아니요, 이러한 함수는 전혀 쓸모가 없으며 Windows에서만 컴파일할 수 있도록 코드를 작성하도록 권장하는 것 외에 다른 목적이 없습니다.

snprintf는 완전히 안전하기 때문에(정확하게 실장되어 있는 경우), snprintf_s는 의미가 없습니다.strcat_s는 버퍼가 오버플로우되면(연결된 스트링을 클리어함으로써) 데이터를 파괴합니다.일이 어떻게 돌아가는지 전혀 모르는 다른 많은 예들이 있다.

실제로 유용한 함수는 BSD strlcpy와 strlcat입니다.그러나 마이크로소프트와 드레퍼 둘 다 그들만의 이기적인 이유로 이러한 것들을 거부했는데, 이는 전 세계 C 프로그래머들이 짜증나게 했다.

자, 이제 TR24731-2를 위한 스탠드입니다.

,, 봤, 봤, 써, 써, 써, yesasprintf()/vasprintf()본 로, 네.glibc 、 、 、 、 、 、 、 、 、 、 、 ever ever ever ever ever ever 。


그들은 내가 필요로 하는 것을 몇 번이고 정확하게 제공하기 때문입니다.강력하고 유연하며 안전하고 (상대적으로) 사용하기 쉬운 방법으로 텍스트를 새로 할당된 문자열로 포맷할 수 있습니다.

합니다.memstream Like(예: Like(예: Like(예: 예))))asprintf(),open_memstream())fmemopen() 큰 에게!!!)은(는)FILE*인쇄를 할 수 있기 때문에, 인쇄 기능이 문자열로 인쇄하고 있는지 파일로 인쇄하고 있는지 전혀 알 수 없습니다.또, 필요한 스페이스의 양을 간단하게 잊어버릴 수 있습니다.

TR24731-1 기능을 지원하는 라이브러리 또는 컴파일러를 사용하고 있습니까?그렇다면 어떤 컴파일러 또는 라이브러리와 플랫폼 상에 있습니까?

네, Visual Studio 2005 및 2008 (Win32 개발용)

이러한 기능을 사용하기 위해 코드를 수정한 결과 버그가 발견되었습니까?

뭐랄까...Linux, Windows, VxWorks, INtime, RTX 및 uItron 등 여러 플랫폼에서 사용되는 안전한 기능의 라이브러리를 작성했습니다.안전 기능을 만든 이유는 다음과 같습니다.

  • 표준 C 함수를 잘못 사용하여 많은 버그가 발생하였습니다.
  • TR 기능이나 경우에 따라서는 POSIX의 대체 기능에 전달 또는 반환되는 정보에 만족하지 못했습니다.

함수가 작성되자 더 많은 버그가 발견되었습니다.네, 그 기능을 사용하는 데 가치가 있었습니다.

가장 큰 가치를 제공하는 기능은 무엇입니까?

vsnprintf, strncpy, strncat의 안전한 버전.

가치도 마이너스도 없는 것이 있습니까?

fopen_s 및 이와 유사한 기능은 개인적으로 거의 가치가 없습니다.fopen이 NULL을 반환해도 괜찮으니 함수의 반환값을 항상 확인해야 합니다.만약 누군가가 fopen의 반환값을 무시한다면, 무엇이 그들에게 fopen_s의 반환값을 확인하게 합니까?fopen_s는 일부 컨텍스트에서 도움이 되는 보다 구체적인 오류 정보를 반환하는 것으로 알고 있습니다.하지만 내가 하고 있는 일은 중요하지 않아

당신은 앞으로 도서관을 이용할 계획입니까?

우리는 지금 그것을 사용하고 있습니다 -- 우리 자신의 "안전한" 도서관 안에서요.

TR24731-2 작업을 추적하고 있습니까?

아니요.

언급URL : https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions

'source' 카테고리의 다른 글

가져오기 및 전달 모드 사용 시도 중: no-cors  (0) 2023.01.17
C와 C++의 산술 연산 전에 단락을 int로 변환해야 하는 이유는 무엇입니까?  (0) 2023.01.17
mysql의 16진수 문자열 감산  (0) 2023.01.17
해시 없이 새 URL로 주소 표시줄 업데이트 또는 페이지 새로고침  (0) 2022.12.24
Python에서 스레드 ID를 얻는 방법  (0) 2022.12.24

'source'의 다른글

  • 현재글TR 24731 '안전' 기능을 사용합니까?

관련글

댓글

티스토리툴바