2016-06-26 1 views
0

Der folgende Code löst eine Heap-Beschädigung aus, wenn versucht wird, lpSubKey freizugeben.Warum verursacht der angegebene Code einen Heap-Fehler?

Was genau läuft schief?

EDIT: Der Fehler wird ausgelöst, auch wenn dies der einzige Code in main() ist, so dass der Fehler nicht an anderer Stelle auftritt.

EDIT2: Aktualisierung des Codes, um die akzeptierte Antwort widerzuspiegeln, hat das Problem gelöst. Ich sehe immer noch nicht, warum es überhaupt einen Fehler gab. Selbst wenn wcscat_s keinen Schutz bot, weil len nicht den korrekten Wert hatte, sollte mein Puffer groß genug sein, um beide Zeichenfolgen zu enthalten.

#define DRIVER_NAME L"TEST" 
#define SUB_KEY  L"System\\CurrentControlSet\\Services\\" 

size_t len = wcslen(SUB_KEY) + wcslen(DRIVER_NAME) + 1; 
LPWSTR lpSubKey = calloc(len, sizeof(WCHAR)); 

wcscat_s(lpSubKey, len, SUB_KEY); 
wcscat_s(lpSubKey, len, DRIVER_NAME); 

free(lpSubKey); 

Antwort

1

Hier gibt es keinen Hinweis auf einen bestimmten Fehler (die Zeichenfolge, die Sie zuweisen, ist groß genug), so dass das Problem wahrscheinlich woanders liegt.

Beachten Sie jedoch, dass wcscat_s die Anzahl von Elementen erfordert, nicht die Größe des Puffers, so dass die _s Versionen der C hier Funktionen schützen Sie nicht in irgendeiner Weise. Ein kohärenter Arbeitsweise (wo len die Anzahl von Zeichen enthält, nicht von Bytes) können sein:

size_t len = (wcslen(SUB_KEY) + wcslen(DRIVER_NAME) + 1); 
LPWSTR lpSubKey = calloc(len, sizeof(WCHAR)); 

wcscat_s(lpSubKey, len, SUB_KEY); 
wcscat_s(lpSubKey, len, DRIVER_NAME); 

free(lpSubKey); 

aktualisieren

Da diese Festsetzung das Problem behoben hat, ich vermute, dass wcscat_s immer absichtlich NUL-terminiert den Puffer bei der len Zeichen, sowohl um sicherzustellen, dass der Puffer immer NUL-terminiert ist, und potenzielle Bugs wie diese offensichtlich zu machen.