주어진 포인터가 "유효"한지 (물론 프로그램 적으로) 결정하는 방법이 있습니까? NULL을 확인하는 것은 쉽지만 0x00001234와 같은 것은 어떻습니까? 이러한 종류의 포인터를 역 참조하려고하면 예외 / 충돌이 발생합니다.
크로스 플랫폼 방법이 선호되지만 플랫폼 별 (Windows 및 Linux 용)도 괜찮습니다.
설명을위한 업데이트 : 문제는 부실 / 해제 / 초기화되지 않은 포인터가 아닙니다. 대신 호출자 (문자열에 대한 포인터, 파일 핸들 등)로부터 포인터를 가져 오는 API를 구현하고 있습니다. 호출자는 (의도적으로 또는 실수로) 잘못된 값을 포인터로 보낼 수 있습니다. 충돌을 어떻게 방지합니까?
답변:
설명을위한 업데이트 : 문제는 오래된 포인터, 해제되었거나 초기화되지 않은 포인터가 아닙니다. 대신 호출자 (문자열에 대한 포인터, 파일 핸들 등)로부터 포인터를 가져 오는 API를 구현하고 있습니다. 호출자는 (의도적으로 또는 실수로) 잘못된 값을 포인터로 보낼 수 있습니다. 충돌을 어떻게 방지합니까?
당신은 그 수표를 만들 수 없습니다. 포인터가 "유효"한지 확인할 수있는 방법은 없습니다. 사람들이 포인터를받는 함수를 사용할 때 그 사람들이 자신이 무엇을하는지 안다는 것을 믿어야합니다. 포인터 값으로 0x4211을 전달하면 0x4211 주소를 가리키는 것을 신뢰해야합니다. 그리고 그들이 "우연히"물체에 부딪힌 경우, 무서운 운영 체제 기능 (IsValidPtr 등)을 사용하더라도 여전히 버그에 빠질 것이며 빠르게 실패하지 않을 것입니다.
이런 종류의 신호를 보내기 위해 널 포인터를 사용하고 라이브러리 사용자에게 실수로 잘못된 포인터를 전달하는 경향이있는 경우 포인터를 사용해서는 안된다고 알리십시오.
다음은 Linux에서 C 프로그램이 실행중인 메모리의 상태에 대해 성찰 할 수있는 세 가지 쉬운 방법과 질문이 일부 컨텍스트에서 적절한 정교한 답변을 갖는 이유입니다.
Microsoft Windows에는 Process Status API (NUMA API에도 있음)에 문서화 된 QueryWorkingSetEx 함수가 있습니다. 정교한 NUMA API 프로그래밍의 결과로서이 함수를 사용하면 간단한 "유효성 테스트 포인터 (C / C ++)"작업을 수행 할 수 있습니다. 따라서 최소 15 년 동안 사용되지 않을 가능성이 높습니다.
호출자가 잘못된 포인터를 전송하여 발생하는 크래시를 방지하는 것은 찾기 어려운 조용한 버그를 만드는 좋은 방법입니다.
API를 사용하는 프로그래머가 코드를 숨기지 않고 충돌시켜 가짜라는 명확한 메시지를 얻는 것이 더 낫지 않습니까?
Win32 / 64에는이를 수행하는 방법이 있습니다. 포인터 읽기를 시도하고 실패시 발생하는 결과 SEH 예외를 포착합니다. 던지지 않으면 유효한 포인터입니다.
이 방법의 문제는 포인터에서 데이터를 읽을 수 있는지 여부를 반환한다는 것입니다. 형식 안전성이나 기타 불변성을 보장하지 않습니다. 일반적으로이 방법은 "예, 지금 지나간 시간에 기억의 특정 위치를 읽을 수 있습니다"라고 말하는 것 외에는 거의 유용하지 않습니다.
간단히 말해서,하지 마십시오;)
Raymond Chen은이 주제에 대한 블로그 게시물 : http://blogs.msdn.com/oldnewthing/archive/2007/06/25/3507294.aspx
AFAIK 방법이 없습니다. 메모리를 해제 한 후 항상 포인터를 NULL로 설정하여 이러한 상황을 피해야합니다.
이 스레드의 답변에 대해서는 다음과 같습니다.
Windows의 경우 IsBadReadPtr (), IsBadWritePtr (), IsBadCodePtr (), IsBadStringPtr ().
내 조언은 그들로부터 멀리 떨어져 있다는 것입니다. 누군가 이미 이것을 게시했습니다 : http://blogs.msdn.com/oldnewthing/archive/2007/06/25/3507294.aspx
같은 주제와 같은 저자 (제 생각에)에 대한 또 다른 게시물은 다음과 같습니다. http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx ( "IsBadXxxPtr은 실제로 CrashProgramRandomly라고해야합니다. ").
API 사용자가 잘못된 데이터를 보내면 충돌이 발생하도록합니다. 문제가 전달 된 데이터가 나중에까지 사용되지 않고 원인을 찾기 어렵게 만드는 경우 문자열 등이 입력시 기록되는 디버그 모드를 추가합니다. 그들이 나쁘다면 그것은 명백 할 것입니다 (그리고 아마도 충돌 할 것입니다). 자주 발생하는 경우 API를 프로세스 외부로 이동하여 기본 프로세스 대신 API 프로세스를 중단시키는 것이 좋습니다.
첫째, 고의로 충돌을 일으키려는 발신자로부터 자신을 보호하려고 노력하는 데 아무런 의미가 없습니다. 그들은 잘못된 포인터를 통해 접근을 시도함으로써 쉽게 이것을 할 수 있습니다. 다른 많은 방법이 있습니다. 메모리 나 스택을 덮어 쓸 수 있습니다. 이런 종류의 일로부터 보호해야하는 경우 통신을 위해 소켓이나 다른 IPC를 사용하여 별도의 프로세스에서 실행해야합니다.
우리는 파트너 / 고객 / 사용자가 기능을 확장 할 수있는 많은 소프트웨어를 작성합니다. 필연적으로 모든 버그가 먼저보고되므로 플러그인 코드에 문제가 있음을 쉽게 보여줄 수 있으면 유용합니다. 또한 보안 문제가 있으며 일부 사용자는 다른 사용자보다 더 신뢰할 수 있습니다.
성능 / 처리량 요구 사항 및 신뢰성에 따라 여러 가지 방법을 사용합니다. 가장 선호하는 항목 :
소켓을 사용하는 별도의 프로세스 (종종 데이터를 텍스트로 전달).
공유 메모리를 사용하는 별도의 프로세스 (대량의 데이터를 전달할 경우).
동일한 프로세스는 메시지 대기열을 통해 스레드를 분리합니다 (짧은 메시지가 자주 발생하는 경우).
동일한 프로세스는 메모리 풀에서 할당 된 모든 전달 된 데이터 스레드를 분리합니다.
직접 프로 시저 호출을 통한 동일한 프로세스-메모리 풀에서 할당 된 모든 전달 된 데이터.
제 3 자 소프트웨어를 다룰 때, 특히 플러그인 / 라이브러리가 소스 코드가 아닌 바이너리로 제공되는 경우 사용자가하려는 작업에 절대로 의존하지 않습니다.
메모리 풀의 사용은 대부분의 상황에서 매우 쉽고 비효율적 일 필요는 없습니다. 처음에 데이터를 할당하는 경우 할당 한 값에 대해 포인터를 확인하는 것은 간단합니다. 할당 된 길이를 저장하고 데이터 앞뒤에 "매직"값을 추가하여 유효한 데이터 유형과 데이터 오버런을 확인할 수도 있습니다.
Unix에서는 다음과 같이 포인터 검사를 수행하고 EFAULT를 반환하는 커널 시스템 호출을 사용할 수 있어야합니다.
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <stdbool.h>
bool isPointerBad( void * p )
{
int fh = open( p, 0, 0 );
int e = errno;
if ( -1 == fh && e == EFAULT )
{
printf( "bad pointer: %p\n", p );
return true;
}
else if ( fh != -1 )
{
close( fh );
}
printf( "good pointer: %p\n", p );
return false;
}
int main()
{
int good = 4;
isPointerBad( (void *)3 );
isPointerBad( &good );
isPointerBad( "/tmp/blah" );
return 0;
}
반환 :
bad pointer: 0x3
good pointer: 0x7fff375fd49c
good pointer: 0x400793
open () [아마도 액세스]보다 더 나은 syscall이있을 것입니다. 이것이 실제 파일 생성 코드 경로로 이어질 가능성이 있고 후속 닫기 요구 사항이 될 수 있기 때문입니다.
나는 거의 동일한 위치에 있기 때문에 귀하의 질문에 많은 동정심을 가지고 있습니다. 나는 많은 응답이 말하는 것에 감사하고 그것들은 정확합니다. 포인터 를 제공하는 루틴 은 유효한 포인터를 제공 해야 합니다. 내 경우에는, 그들이 포인터를 손상 수 있었다는 것을 거의 상상할 수있다 - 그러나이 경우 한 관리, 내 소프트웨어가 될 것이라고 비난을받을 것이다 충돌 및 ME :-(
내 요구 사항은 세분화 오류 후에도 계속하는 것이 아닙니다. 위험 할 수 있습니다. 고객이 나를 비난하는 대신 코드를 수정할 수 있도록 종료하기 전에 발생한 일을 고객에게보고하고 싶습니다.
이것이 내가 그것을 (Windows에서) 찾은 방법입니다 : http://www.cplusplus.com/reference/clibrary/csignal/signal/
시놉시스를 제공하려면 :
#include <signal.h>
using namespace std;
void terminate(int param)
/// Function executed if a segmentation fault is encountered during the cast to an instance.
{
cerr << "\nThe function received a corrupted reference - please check the user-supplied dll.\n";
cerr << "Terminating program...\n";
exit(1);
}
...
void MyFunction()
{
void (*previous_sigsegv_function)(int);
previous_sigsegv_function = signal(SIGSEGV, terminate);
<-- insert risky stuff here -->
signal(SIGSEGV, previous_sigsegv_function);
}
이제이 나타납니다 (이 에러 메시지를 출력하고 프로그램을 종료) 나는 희망으로 행동하는 -하지만 누군가가 결함을 발견 할 수 있다면, 알려 주시기 바랍니다!
exit()RAII를 우회하므로 리소스 누수가 발생할 수 있습니다.
exit()휴대용 C ++ 알람 벨이 울리기 시작했습니다. 프로그램이 어쨌든 종료되는이 Linux 특정 상황에서는 괜찮을 것입니다.
man 2 signalLinux에는 이유를 설명하는 단락이 있습니다.
C ++에는 일반적인 경우로서 포인터의 유효성을 테스트 할 수있는 조항이 없습니다. NULL (0x00000000)이 나쁘다고 가정 할 수 있으며, 다양한 컴파일러와 라이브러리는 디버깅을 더 쉽게하기 위해 여기 저기에서 "특수 값"을 사용하는 것을 좋아합니다 (예를 들어 Visual Studio에서 포인터가 0xCECECECE로 표시되는 것을 본 경우 나는 뭔가 잘못했다) 그러나 진실은 포인터가 단지 메모리에 대한 인덱스이기 때문에 그것이 "올바른"인덱스인지 포인터를 보는 것만으로는 거의 불가능하다는 것입니다.
가리키는 객체가 원하는 유형인지 확인하기 위해 dynamic_cast 및 RTTI로 수행 할 수있는 다양한 트릭이 있지만, 모두 처음부터 유효한 것을 가리켜 야합니다.
프로그램이 "유효하지 않은"포인터를 감지 할 수 있는지 확인하려면 내 조언은 다음과 같습니다. 선언하는 모든 포인터를 생성 즉시 NULL 또는 유효한 주소로 설정하고 가리키는 메모리를 해제 한 후 즉시 NULL로 설정합니다. 이 관행에 부지런한 경우 NULL을 확인하는 것만으로도 충분합니다.
이를 수행하는 이식 가능한 방법은 없으며 특정 플랫폼에 대해 수행하는 것은 어렵거나 불가능할 수 있습니다. 어떤 경우에도 이러한 검사에 의존하는 코드를 작성해서는 안됩니다. 처음부터 포인터가 잘못된 값을 사용하도록하지 마십시오.
사용 전후에 포인터를 NULL로 설정하는 것은 좋은 기술입니다. 예를 들어 (문자열) 클래스 내에서 포인터를 관리하는 경우 C ++에서 쉽게 수행 할 수 있습니다.
class SomeClass
{
public:
SomeClass();
~SomeClass();
void SetText( const char *text);
char *GetText() const { return MyText; }
void Clear();
private:
char * MyText;
};
SomeClass::SomeClass()
{
MyText = NULL;
}
SomeClass::~SomeClass()
{
Clear();
}
void SomeClass::Clear()
{
if (MyText)
free( MyText);
MyText = NULL;
}
void SomeClass::Settext( const char *text)
{
Clear();
MyText = malloc( strlen(text));
if (MyText)
strcpy( MyText, text);
}
퍼블릭 API에서 임의의 포인터를 입력 매개 변수로 받아들이는 것은 좋은 정책이 아닙니다. 정수, 문자열 또는 구조체와 같은 "일반 데이터"유형을 갖는 것이 더 좋습니다 (물론 일반 데이터가 포함 된 고전적 구조체를 의미합니다. 공식적으로 모든 것이 구조체가 될 수 있음).
왜? 다른 사람들이 말하는 것처럼 유효한 포인터를 받았는지 아니면 정크를 가리키는 포인터를 받았는지 알 수있는 표준 방법이 없기 때문입니다.
하지만 때로는 선택의 여지가 없습니다. API는 포인터를 받아야합니다.
이 경우 좋은 포인터를 전달하는 것은 호출자의 의무입니다. NULL은 값으로 허용 될 수 있지만 정크에 대한 포인터는 아닙니다.
어떤 식 으로든 다시 확인할 수 있습니까? 글쎄, 그런 경우에 내가 한 일은 포인터가 가리키는 유형에 대한 불변을 정의하고 얻을 때 (디버그 모드에서) 호출하는 것이 었습니다. 적어도 불변이 실패 (또는 충돌)하면 잘못된 값이 전달되었음을 알 수 있습니다.
// API that does not allow NULL
void PublicApiFunction1(Person* in_person)
{
assert(in_person != NULL);
assert(in_person->Invariant());
// Actual code...
}
// API that allows NULL
void PublicApiFunction2(Person* in_person)
{
assert(in_person == NULL || in_person->Invariant());
// Actual code (must keep in mind that in_person may be NULL)
}
다른 사람들이 말했듯이 잘못된 포인터를 안정적으로 감지 할 수 없습니다. 유효하지 않은 포인터가 취할 수있는 몇 가지 형식을 고려하십시오.
널 포인터가있을 수 있습니다. 그것은 당신이 쉽게 확인하고 뭔가를 할 수있는 것입니다.
유효한 메모리 외부에 대한 포인터를 가질 수 있습니다. 유효한 메모리를 구성하는 것은 시스템의 런타임 환경이 주소 공간을 설정하는 방법에 따라 다릅니다. Unix 시스템에서는 일반적으로 0에서 시작하여 많은 수의 메가 바이트로 이동하는 가상 주소 공간입니다. 임베디드 시스템에서는 매우 작을 수 있습니다. 어떤 경우에도 0에서 시작하지 않을 수 있습니다. 앱이 감독자 모드 또는 이와 동등한 모드에서 실행되는 경우 포인터가 실제 주소를 참조 할 수 있으며, 실제 주소는 실제 메모리로 백업되거나 백업되지 않을 수 있습니다.
데이터 세그먼트, bss, 스택 또는 힙 내부에서도 유효한 메모리 내부 어딘가에 대한 포인터를 가질 수 있지만 유효한 개체를 가리키는 것은 아닙니다. 이것의 변형은 개체에 문제가 발생하기 전에 유효한 개체를 가리키는 데 사용되는 포인터입니다. 이 맥락에서 나쁜 것은 할당 해제, 메모리 손상 또는 포인터 손상을 포함합니다.
참조되는 항목에 대해 잘못된 정렬이있는 포인터와 같이 평면이 아닌 잘못된 포인터가있을 수 있습니다.
세그먼트 / 오프셋 기반 아키텍처 및 기타 이상한 포인터 구현을 고려하면 문제가 더욱 악화됩니다. 이런 종류의 일은 일반적으로 좋은 컴파일러와 현명한 유형의 사용으로 인해 개발자에게 숨겨져 있지만 베일을 뚫고 운영 체제와 컴파일러 개발자를 능가하려는 경우 할 수 있지만 일반적인 방법은 없습니다. 발생할 수있는 모든 문제를 처리 할 수 있습니다.
최선의 방법은 충돌을 허용하고 좋은 진단 정보를 제공하는 것입니다.
이 기사 MEM10-C. 포인터 유효성 검사 기능을 정의하고 사용하면 특히 Linux OS에서 어느 정도 검사를 수행 할 수 있습니다.
일반적으로 불가능합니다. 특히 불쾌한 경우가 있습니다.
struct Point2d {
int x;
int y;
};
struct Point3d {
int x;
int y;
int z;
};
void dump(Point3 *p)
{
printf("[%d %d %d]\n", p->x, p->y, p->z);
}
Point2d points[2] = { {0, 1}, {2, 3} };
Point3d *p3 = reinterpret_cast<Point3d *>(&points[0]);
dump(p3);
많은 플랫폼에서 다음과 같이 출력됩니다.
[0 1 2]
런타임 시스템이 메모리 비트를 잘못 해석하도록 강요하지만,이 경우 비트가 모두 의미가 있기 때문에 충돌하지 않을 것입니다. 이것은 (와 C 스타일의 다형성 봐 언어의 설계의 일부입니다 struct inaddr, inaddr_in, inaddr_in6당신이 안정적으로 모든 플랫폼에 대해 보호 할 수 있도록).
위의 기사에서 얼마나 많은 오해의 소지가있는 정보를 읽을 수 있는지 믿을 수 없습니다.
그리고 Microsoft msdn 문서에서도 IsBadPtr은 금지되었다고 주장됩니다. 오 글쎄-나는 충돌보다는 작동하는 응용 프로그램을 선호합니다. 용어 작업이 잘못 작동하더라도 (최종 사용자가 응용 프로그램을 계속할 수있는 한).
인터넷 검색을 통해 Windows에 대한 유용한 예를 찾지 못했습니다. 32 비트 앱에 대한 솔루션을 찾았습니다.
하지만 64 비트 앱도 지원해야하므로이 솔루션이 작동하지 않았습니다.
하지만 와인의 소스 코드를 모아서 64 비트 앱에서도 작동하는 비슷한 종류의 코드를 만들었습니다. 여기에 코드를 첨부하세요.
#include <typeinfo.h>
typedef void (*v_table_ptr)();
typedef struct _cpp_object
{
v_table_ptr* vtable;
} cpp_object;
#ifndef _WIN64
typedef struct _rtti_object_locator
{
unsigned int signature;
int base_class_offset;
unsigned int flags;
const type_info *type_descriptor;
//const rtti_object_hierarchy *type_hierarchy;
} rtti_object_locator;
#else
typedef struct
{
unsigned int signature;
int base_class_offset;
unsigned int flags;
unsigned int type_descriptor;
unsigned int type_hierarchy;
unsigned int object_locator;
} rtti_object_locator;
#endif
/* Get type info from an object (internal) */
static const rtti_object_locator* RTTI_GetObjectLocator(void* inptr)
{
cpp_object* cppobj = (cpp_object*) inptr;
const rtti_object_locator* obj_locator = 0;
if (!IsBadReadPtr(cppobj, sizeof(void*)) &&
!IsBadReadPtr(cppobj->vtable - 1, sizeof(void*)) &&
!IsBadReadPtr((void*)cppobj->vtable[-1], sizeof(rtti_object_locator)))
{
obj_locator = (rtti_object_locator*) cppobj->vtable[-1];
}
return obj_locator;
}
그리고 다음 코드는 포인터가 유효한지 여부를 감지 할 수 있으므로 NULL 검사를 추가해야합니다.
CTest* t = new CTest();
//t = (CTest*) 0;
//t = (CTest*) 0x12345678;
const rtti_object_locator* ptr = RTTI_GetObjectLocator(t);
#ifdef _WIN64
char *base = ptr->signature == 0 ? (char*)RtlPcToFileHeader((void*)ptr, (void**)&base) : (char*)ptr - ptr->object_locator;
const type_info *td = (const type_info*)(base + ptr->type_descriptor);
#else
const type_info *td = ptr->type_descriptor;
#endif
const char* n =td->name();
이것은 포인터에서 클래스 이름을 가져옵니다-귀하의 요구에 충분해야한다고 생각합니다.
내가 여전히 두려워하는 한 가지는 포인터 검사의 성능입니다. 위의 코드 스 니펫에는 이미 3-4 개의 API 호출이 수행되고 있습니다. 시간이 중요한 애플리케이션에서는 과도 할 수 있습니다.
예를 들어 C # / 관리되는 C ++ 호출과 비교하여 누군가가 포인터 검사의 오버 헤드를 측정 할 수 있다면 좋을 것입니다.
다음은 Windows에서 작동합니다 (누군가가 전에 제안했습니다).
static void copy(void * target, const void* source, int size)
{
__try
{
CopyMemory(target, source, size);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
doSomething(--whatever--);
}
}
함수는 일부 클래스의 정적, 독립형 또는 정적 메서드 여야합니다. 읽기 전용으로 테스트하려면 로컬 버퍼에 데이터를 복사하십시오. 내용을 수정하지 않고 쓰기 테스트를하려면 덮어 씁니다. 첫 번째 / 마지막 주소 만 테스트 할 수 있습니다. 포인터가 유효하지 않으면 제어가 'doSomething'에 전달 된 다음 대괄호 외부에 전달됩니다. CString과 같이 소멸자가 필요한 것은 사용하지 마십시오.
Windows에서는 다음 코드를 사용합니다.
void * G_pPointer = NULL;
const char * G_szPointerName = NULL;
void CheckPointerIternal()
{
char cTest = *((char *)G_pPointer);
}
bool CheckPointerIternalExt()
{
bool bRet = false;
__try
{
CheckPointerIternal();
bRet = true;
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
}
return bRet;
}
void CheckPointer(void * A_pPointer, const char * A_szPointerName)
{
G_pPointer = A_pPointer;
G_szPointerName = A_szPointerName;
if (!CheckPointerIternalExt())
throw std::runtime_error("Invalid pointer " + std::string(G_szPointerName) + "!");
}
용법:
unsigned long * pTest = (unsigned long *) 0x12345;
CheckPointer(pTest, "pTest"); //throws exception
Windows의 경우 IsBadReadPtr (), IsBadWritePtr (), IsBadCodePtr (), IsBadStringPtr ().
이것들은 블록의 길이에 비례하여 시간이 걸리므로 온 전성 확인을 위해 시작 주소 만 확인합니다.
기술적으로는 operator new (및 delete )를 재정의 하고 할당 된 모든 메모리에 대한 정보를 수집 할 수 있으므로 힙 메모리가 유효한지 확인하는 방법을 가질 수 있습니다. 그러나:
포인터가 스택 ()에 할당되었는지 확인하는 방법이 여전히 필요합니다.
'유효한'포인터가 무엇인지 정의해야합니다.
a) 해당 주소의 메모리가 할당됩니다.
b) 해당 주소의 메모리 는 객체의 시작 주소입니다 (예 : 거대한 배열의 중간에 있지 않은 주소).
c) 해당 주소의 메모리 는 예상 유형 의 객체의 시작 주소입니다.
결론 : 문제의 접근 방식은 C ++ 방식이 아닙니다. 함수가 유효한 포인터를 받도록하는 몇 가지 규칙을 정의해야합니다.
C ++에서 확인하는 방법은 없습니다. 다른 코드가 잘못된 포인터를 전달하는 경우 어떻게해야합니까? 충돌해야합니다. 왜? 이 링크를 확인하십시오 : http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx
승인 된 답변에 대한 부록 :
포인터가 0, 1 및 -1의 세 값만 보유 할 수 있다고 가정합니다. 여기서 1은 유효한 포인터, -1은 유효하지 않은 포인터, 0은 유효하지 않은 포인터를 나타냅니다. 포인터 가 NULL이고 모든 값이 같을 확률은 얼마입니까? 1/3. 이제 유효한 케이스를 꺼내서 모든 유효하지 않은 케이스에 대해 50:50 비율로 모든 오류를 포착합니다. 좋아 보이지? 4 바이트 포인터에 대해이 크기를 조정하십시오. 2 ^ 32 또는 4294967294 가능한 값이 있습니다. 이 중 하나의 값만 정확하고 하나는 NULL이며 여전히 다른 잘못된 경우 4294967292가 남아 있습니다. 재 계산 : 유효하지 않은 케이스 (4294967292+ 1) 중 1 개에 대한 테스트가 있습니다. 대부분의 실제 목적에서 2.xe-10 또는 0의 확률입니다. 이것이 NULL 검사의 무익함입니다.
이러한 방법은 작동하지 않으므로 피해야합니다. blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx – JaredPar 2009 년 2 월 15 일 16:02
작동하지 않으면 다음 Windows 업데이트가 문제를 해결합니까? 개념 수준에서 작동하지 않으면 기능이 Windows API에서 완전히 제거 될 수 있습니다.
MSDN 문서는 그것들이 금지되어 있다고 주장하며, 그 이유는 아마도 추가 응용 프로그램 디자인의 결함 일 것입니다 (예를 들어, 일반적으로 전체 응용 프로그램의 디자인을 담당하는 경우 일반적으로 잘못된 포인터를 조용히 먹어서는 안 됨) 및 성능 / 시간 포인터 검사의.
그러나 일부 블로그 때문에 작동하지 않는다고 주장해서는 안됩니다. 내 테스트 응용 프로그램에서 작동하는지 확인했습니다.
이 링크가 도움이 될 수 있습니다.
_CrtIsValidPointer 지정된 메모리 범위가 읽기 및 쓰기에 유효한지 확인합니다 (디버그 버전 만 해당). http://msdn.microsoft.com/en-us/library/0w1ekd5e.aspx
_CrtCheckMemory 디버그 힙에 할당 된 메모리 블록의 무결성을 확인합니다 (디버그 버전 만 해당). http://msdn.microsoft.com/en-us/library/e73x0s4b.aspx