<div id="readability-page-1" class="page"><div id="SE-6c7b3a55-354a-4ee2-b25a-4137b6bb8354">
 레이몬드 챈의 블로그에 포스팅한 "Functions that return the size of a required buffer generally return upper bounds, not tight bounds" 글을 쉽게 이해할 수 있도록 편역하였습니다.​​윈도API 중 필요한 버퍼의 크기를 반환하는 함수들은 일반적으로 정확한 크기가 아닌 의도보다 큰 값을 반환하는 경우가 있는데 이 이유와, 아울러 간혹 만나게 되는 "�����������" 혹은 "??????????" 문자열이 표시되는 이유도 알 수 있습니다.​윈도API 중 다음의 세 단계 순서를 통해 사용하는 몇개의 함수가 있습니다. 일반적으로 아래와 같은 순서로 코드를 작성합니다.:​ (1단계) 데이터를 담기위해 필요한 버퍼의 크기를 요청 (2단계) 요청한 크기 만큼의 버퍼를 할당 (3단계) 할당된 버퍼를 인자로 함수를 다시 호출​해당 API는 RegQueryInfoKey, GetWindowsTextLength, GetModuleFileName, GetSystemDirectory, GetUserName와 같은 것들이 있으며, 위 세단계 작업을 코드로 나타내면 아래와 같습니다.
 </div><div id="SE-3c7d44d0-caf5-4b50-a47b-2393ecda51de">
 1단계에서 필요한 버퍼의 크기를 요청하면 함수는 3단계의 데이터 실제크기보다 더 큰 값을 반환하는 일이 종종 있습니다. 왜 그럴까요? 왜 첫 번째 함수는 나에게 넉넉한 크기를 알려줄까요?​일반적인 이유중 하나는 첫 번째 요청 시점은 검사 시점고 두 번째 요청 시점은 사용 시점인데, 두 시점 사이의 시간차이(TOCTTOU; time-of-check-to-time-of-use)로 1단계 요청값과 실제 데이터를 버퍼에 받았을 때 크기가 다를 수 있습니다. 크기가 달라진 것이라기 보다 상황이 변했기 때문에 결과가 달라진 것입니다.​개발자는 어짜피 크기의 변화에 대비한 코드를 작성(MAX_PATH, length + 1 등)하는 습관이 있고, 항상 큰 버퍼에 작은 데이터를 넣기 때문에 실제 필요한 크기보다 약간 더 큰 값을 반환하는 것은 문제가 되지 않습니다. 이렇게 하면 데이터가 변경되지 않았다고 가정했을 때, 실제 데이터를 요청하는 두 번째 호출이 성공적으로 이루어질 수 있습니다. 실제 필요한 정확한 값을 계산하는 것보다 넉넉한 추정치를 제공하는 것이 훨씬 더 간단하게 모두를 만족시키는 경우가 많습니다.​또다른 이유는, 예를 들어, 윈도우의 텍스트 길이를 요청하는 GetWindowTextLengthA 함수 호출은 GetWindowTextLengthW를 호출하고 UTF-16(유니코드를 표현하기 위한 방식중 하나) 코드 단위의 길이를 8비트 문자 집합으로 변환하게 되는데, 정확한 바이트 길이를 계산하기 위해 계산하기 쉬운 케이스와 계산하기 어려운 케이스를 고려하는 복잡한 변환 과정을 거치게 됩니다. 쉽게 다시 설명하기 위해 계산하기 쉬운 케이스와 어려운 케이스를 구분하여 설명해 보겠습니다.​(계산하기 쉬운 케이스) ASCII 문자 집합은 7비트로 구성되어 있어 128개의 문자를 표현할 수 있으며, 이는 주로 영문 알파벳, 숫자, 그리고 일반적인 기호를 포함합니다. UTF-16 인코딩에서 이 ASCII 문자들은 여전히 2바이트를 사용하지만, 실제로 문자를 표현하는데는 첫 번째 바이트만 사용되며 두 번째 바이트는 0이 됩니다. 이러한 문자들은 8비트 문자 집합으로도 잘 변환됩니다. 예를 들어, 문자 "A"는 ASCII에서 10진수 65의 값을 가지며, UTF-16에서는 동일하게 16진수 0x0041로 표현됩니다. 이 경우 첫 번째 바이트는 0x41이고 두 번째 바이트는 0x00입니다. 이 "A" 문자를 8비트 문자 집합으로 변환하면, 단순히 0x41 값만 사용되므로, 변환 과정에서 문제가 발생하지 않습니다. 결과적으로 UTF-16에서 "A" 문자는 8비트 문자 집합에서도 "A"로 잘 표현되며, 정보 손실 없이 1바이트를 사용하여 표현됩니다. 이와 같이, UTF-16에서 ASCII 범위에 속하는 문자들은 8비트 문자 집합으로 변환할 때 원활하게 변환되며, 문자의 의미나 표현에 변화가 없습니다.​(계산하기 어려운 케이스) 유니코드에는 다른 문자집합 갯수보다 더 많기 때문에, 모든 유니코드 문자를 단일 16비트 코드 유닛으로 표현할 수 없습니다. 이를 해결하기 위해 일부 문자는 2개의 16비트 코드 유닛인 서로게이트 쌍(surrogate pair)을 사용하여 표현됩니다. 이렇게 하면 더 많은 문자를 표현할 수 있습니다. 그러나 이 문자들을 8비트 문자 집합(예: ASCII 또는 ISO 8859-1)으로 변환할 때 문제가 발생할 수 있습니다. 이런 8비트 문자 집합은 보통 문자 하나를 표현하기 위해 1바이트만을 사용합니다. 예를 들어 유니코드 문자 "😊"(U+1F60A, 스마일 이모지)는 UTF-16에서 서로게이트 쌍으로 표현됩니다. 이 문자는 2개의 16비트 코드 유닛으로 구성되며, 각각 2바이트를 차지합니다. 따라서, "😊"는 총 4바이트를 사용하여 UTF-16에서 표현됩니다. 이제 이 문자를 8비트 문자 집합으로 변환하려고 하면 이모지 같은 복잡한 문자는 해당 문자 집합에 존재하지 않기때문에 변환 과정에서 대체 문자로 변환될 수 있습니다. 대부분의 경우 "�"(U+FFFD, 대체 문자)나 "?"와 같은 물음표로 표현됩니다. 이는 원본 문자와 다른 단일 8비트 문자로의 축소로 귀결됩니다.​따라서, UTF-16에서 서로게이트 쌍을 사용하는 문자를 8비트 문자 집합으로 변환할 때는 정확한 바이트 크기를 예측하기 어려울 수 있으며, 이로 인해 변환된 문자의 크기가 원본과 다를 수 있습니다. 바이트로의 정확한 길이 계산은 임시 메모리를 할당하고, UTF-16으로 문자열을 임시 버퍼에 읽은 다음, 문자 변환을 수행하여 진짜 길이를 얻고, 그런 다음 임시 버퍼를 해제하는 일련의 과정을 거쳐야 합니다.​이 모든 작업은 개발자도 동일한 작업을 수행하기 때문에 중복된 작업입니다​그래서 필요한 버퍼 크기를 가져오기 위한 호출이 실제보다 큰 값을 반환하는 것은 크게 중요치 않은 부분에서 효율성을 높인 대안입니다. 일반적인 API 사용 패턴을 고려할 때 실제로 해야 하는 의무는 버퍼 크기의 상한선을 제공하는 것으로 충분합니다. 정확한 버퍼 크기를 제공하는 것은 비효율적입니다.​참고 사항 : 구체적인 예로, RegQueryInfoKey는 값과 서브키의 최대 길이를 리턴하지만, 이들은 정확한 상한선이 아니라 추정값입니다. 문자 변환 추정치만이 고려되는 것은 아닙니다. 최대값 혹은 서브키가 삭제될 때 정확한 최대 길이를 다시 계산하는 것은 아이템을 선형 검색하거나 값과 서브키를 내림차순 길이별로 정렬하는 별도의 인덱스를 유지하는 작업이 필요 합니다. 윈도 레지스트리는 이런 동작을 하지 않습니다. 그저 최고점을 추정할 뿐입니다. 하지만, API가 반환한 값이 너무 클 수는 있지만, 결코 작은 경우는 없습니다.​
 </div></div>

내 성격 100% 활용하기 -上-

레이몬드 챈의 블로그에 포스팅한 "Functions that return the size of a required buffer generally return upper bounds, not tight bounds" 글을 쉽게 이해할 수 있도록 편역하였습니다. 윈도API 중 필요한 버퍼의 크기를 반환하는 함수들은 일반적으로 정확한 크기가 아닌 의도보다 큰 값을 반환하는 경우가 있는데 이 이유와, 아울러 간혹 만나게 되는 "�����������" 혹은 "??????????" 문자열이 표시되는 이유도 알 수 있습니다. 윈도API 중 다음의 세 단계 순서를 통해 사용하는 몇개의 함수가 있습니다. 일반적으로 아래와 같은 순서로 코드를 작성합니다.: (1단계) 데이터를 담기위해 필요한.......

버퍼 크기를 리턴하는 윈도API의 의도보다 큰 리턴값

댓글