C 라이브러리의 함수는 항상 문자열 길이를 예상해야합니까?

현재 C로 작성된 라이브러리에서 작업하고 있습니다.이 라이브러리의 많은 함수는 인수 로 char*또는 문자열로 문자열을 기대합니다 const char*. size_tnull 종료가 필요하지 않도록 항상 문자열의 길이를 기대하는 함수로 시작했습니다 . 그러나 테스트를 작성할 때 strlen()다음과 같이 자주 사용되었습니다 .

const char* string = "Ugh, strlen is tedious";
libFunction(string, strlen(string));

사용자가 올바르게 종료 된 문자열을 전달하도록하면 덜 안전하지만 더 간결하고 읽기 쉬운 코드가됩니다.

libFunction("I hope there's a null-terminator there!");

그래서, 현명한 연습은 무엇입니까? API 사용을 더 복잡하게 만들지 만 사용자가 입력을 생각하거나 null로 끝나는 문자열에 대한 요구 사항을 문서화하고 호출자를 신뢰하도록 강요합니까?

가장 확실하고 절대적으로 길이를 가지고 다니십시오 . 표준 C 라이브러리는 이런 식으로 악의적으로 파괴되어 버퍼 오버플로를 처리하는 데 어려움을 겪지 않았습니다. 이 접근법은 현대의 컴파일러가 이런 종류의 표준 라이브러리 함수를 사용할 때 실제로 경고하고, 울리고, 불평 할 정도로 많은 증오와 고뇌의 초점입니다.

인터뷰에서이 질문을 접한 적이 있고 기술 면접관이 몇 년 동안 경험을 쌓은 것처럼 보이면 순수 열광자가 직업을 착륙시킬 수 있습니다. C 문자열 종결자를 찾는 API를 구현하는 사람 을 촬영하는 선례 .

그것의 감정을 제쳐두고, 문자열의 끝에서 NULL을 읽거나 조작하는 데 잘못 될 수있는 많은 것들이 있습니다-게다가 그것은 심층 방어와 같은 현대적인 디자인 개념을 직접 위반하는 것입니다 (보안에 반드시 적용되는 것이 아니라 API 디자인에 적용됨). 길이가 많은 C API의 예-예. Windows API.

실제로,이 문제는 90 년대 언젠가 해결되었는데, 오늘날 떠오르는 합의는 현을 만져서는 안된다는 것 입니다.

나중에 편집 : 당신은 같은 고전 물건을 볼 때까지 나는 OK가 아래로하고 위의 모든 사람을 신뢰하는 것은 좋은 것을 추가 * 기능을 라이브러리 STR을 사용합니다 있도록이 상당히 라이브 논쟁이다 output = malloc(strlen(input)); strcpy(output, input);또는 while(*src) { *dest=transform(*src); dest++; src++; }. 나는 배경에서 모차르트의 Lacrimosa를 거의들을 수있다.

C에서 관용구는 문자열이 NUL로 끝나는 것이므로 일반적인 관례를 따르는 것이 합리적입니다. 실제로 라이브러리 사용자가 NUL로 끝나지 않은 문자열을 가질 가능성은 상대적으로 적습니다 (인쇄에 추가 작업이 필요하기 때문에) printf를 사용하고 다른 상황에서 사용). 다른 종류의 줄을 사용하는 것은 부자연스럽고 아마도 비교적 드 rare니다.

또한 상황에 따라 테스트가 나에게 조금 이상하게 보입니다. (스트 렌을 사용하여) 올바르게 작동하기 때문에 먼저 NUL 종료 문자열을 가정하고 있습니다. 라이브러리에서 작동하도록하려면 NUL이 아닌 문자열의 경우를 테스트해야합니다.

"안전성"주장은 실제로 유지되지 않습니다. 문서화 된 내용 (및 평범한 C의 표준)이있을 때 사용자가 null로 끝나는 문자열을 넘겨 줄 것을 믿지 않으면 실제로 그들이 제공 한 길이를 신뢰할 수 없습니다. 아마 strlen그들이 편리하지 않으면 당신이하고있는 것처럼 사용하여 얻을 수 있으며 , "문자열"이 처음에 문자열이 아니면 실패 할 것입니다).

길이가 필요한 유효한 이유가 있습니다. 함수를 서브 스트링에서 사용하려면 사용자가 널 바이트를 얻기 위해 마법을 앞뒤로 복사하는 것보다 길이를 전달하는 것이 훨씬 쉽고 효율적입니다. 올바른 장소에서 (그리고 도중에 오류가 발생할 위험이 있습니다).
널 바이트가 종료가 아닌 인코딩을 처리 할 수 ​​있거나 널 (임의로)이 포함 된 문자열을 처리 할 수 ​​있으면 일부 상황에서 유용 할 수 있습니다 (함수의 기능에 따라 다름).
널이 아닌 종료 데이터 (고정 길이 배열)도 처리 할 수 ​​있습니다.
간단히 말해서 : 라이브러리에서 수행중인 작업과 사용자가 처리 할 것으로 예상되는 데이터 유형에 따라 다릅니다.

이에 대한 성능 측면도있을 수 있습니다. 함수가 문자열의 길이를 미리 알아야하고 사용자가 최소한 일반적으로 해당 정보를 알고 있기 때문에 정보를 계산하지 않고 전달하면 몇 번의주기를 줄일 수 있습니다.

그러나 라이브러리에 일반 일반 ASCII 텍스트 문자열이 필요하고 성능에 제약이없고 사용자가 라이브러리와 상호 작용하는 방식을 잘 이해하고 있다면 길이 매개 변수를 추가하는 것은 좋은 생각처럼 들리지 않습니다. 문자열이 올바르게 종료되지 않으면 길이 매개 변수가 가짜 일 가능성이 있습니다. 나는 당신이 그것으로 많은 것을 얻을 것이라고 생각하지 않습니다.

아니요. 문자열은 항상 정의에 의해 null로 끝나고 문자열 길이는 중복됩니다.

널이 아닌 문자 데이터는 "문자열"이라고해서는 안됩니다. 그것을 처리하고 (길이를 던지는) 일반적 으로 API의 일부가 아닌 라이브러리 내에 캡슐화 되어야 합니다. 단일 strlen () 호출을 피하기 위해 길이를 매개 변수로 요구하는 것은 조기 최적화 일 가능성이 높습니다.

API 함수의 호출자를 신뢰하는 것은 안전하지 않습니다 . 문서화 된 전제 조건이 충족되지 않으면 정의되지 않은 동작은 완벽하게 정상입니다.

물론 잘 설계된 API에는 함정이 없어야하며 올바르게 사용하기가 쉬워야합니다. 그리고 이것은 중복을 피하고 언어 관습에 따라 가능한 한 간단하고 간단해야 함을 의미합니다.

항상 길이를 유지해야합니다. 예를 들어, 사용자는 NULL을 포함 할 수 있습니다. 두 번째로, strlenO (N)이며 모든 byby by by cache를 터치해야합니다. 셋째, 서브셋을 쉽게 전달할 수 있습니다. 예를 들어 서브셋은 실제 길이보다 줄어 듭니다.

문자열 을 전달하는 것과 버퍼를 전달 하는 것을 구별해야합니다 .

C에서 문자열은 전통적으로 NUL로 종료됩니다. 이것을 기대하는 것은 전적으로 합리적입니다. 따라서 일반적으로 문자열 길이를 전달할 필요가 없습니다. strlen필요한 경우 계산할 수 있습니다 .

전세계 거의 통과 할 때 버퍼 에 기록되고, 특히 하나를, 당신은 절대적으로 버퍼 크기에 따라 전달해야합니다. 대상 버퍼의 경우이를 통해 수신자는 버퍼 오버플로를 방지 할 수 있습니다. 입력 버퍼의 경우, 특히 입력 버퍼에 신뢰할 수없는 소스에서 시작된 임의의 데이터가 포함 된 경우 수신자는 끝을 지나서 읽지 않도록 할 수 있습니다.

문자열과 버퍼가 모두있을 수 있고 char*많은 문자열 함수가 대상 버퍼에 기록하여 새 문자열을 생성 하기 때문에 약간의 혼동이있을 수 있습니다 . 어떤 사람들은 문자열 함수가 문자열 길이를 가져야한다고 결론을 내립니다. 그러나 이것은 부정확 한 결론입니다. 버퍼에 크기를 포함시키는 방법 (문자열, 정수 배열, 구조 등에 버퍼를 사용하는지 여부)은보다 유용하고 일반적인 만트라입니다.

(신뢰할 수없는 소스 (예 : 네트워크 소켓)에서 문자열을 읽는 경우 입력이 NUL로 종료되지 않을 수 있으므로 길이를 제공하는 것이 중요 하지만 입력을 문자열로 간주 해서는 안됩니다 . 문자열을 포함 할 수 있는 임의의 데이터 버퍼로 처리해야 합니다 (그러나 실제로 유효성을 검사 할 때까지 알지 못합니다). 그래서 버퍼 크기와 관련하여 문자열에 필요하지 않다는 원칙을 따릅니다.

함수가 주로 문자열 리터럴과 함께 사용되는 경우 일부 매크로를 정의하여 명시적인 길이를 다루는 고통을 최소화 할 수 있습니다. 예를 들어, API 함수가 주어진 경우 :

void use_string(char *string, int length);

매크로를 정의 할 수 있습니다.

#define use_strlit(x) use_string(x, sizeof ("" x "")-1)

다음과 같이 호출하십시오.

void test(void)
{
  use_strlit("Hello");
}

컴파일되지만 실제로는 작동하지 않는 매크로를 전달하는 "크리에이티브"항목을 만들 수 있지만 """sizeof"평가에서 문자열의 양쪽에서 사용하면 실수로 문자를 사용하려는 시도를 잡아야합니다. 분해 된 문자열 리터럴 이외의 포인터 [이없는 경우 ""문자 포인터를 전달하려는 시도는 길이를 포인터 크기에서 1을 뺀 값으로 잘못 제공합니다.

C99의 대안은 "포인터 및 길이"구조 유형을 정의하고 문자열 리터럴을 해당 구조 유형의 복합 리터럴로 변환하는 매크로를 정의하는 것입니다. 예를 들면 다음과 같습니다.

struct lstring { char const *ptr; int length; };
#define as_lstring(x) \
  (( struct lstring const) {x, sizeof("" x "")-1})

그러한 접근 방식을 사용하는 경우 주소를 전달하지 않고 값으로 이러한 구조를 전달해야합니다. 그렇지 않으면 :

struct lstring *p;
if (foo)
{
  p = &as_lstring("Hello");
}
else
{
  p = &as_lstring("Goodbye!");
}
use_lstring(p);

복합 리터럴의 수명이 해당 명령문의 끝에서 끝나기 때문에 실패 할 수 있습니다.