Skip to content

typo: arugments -> arguments #2132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 31, 2018
Merged

typo: arugments -> arguments #2132

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/debugger/allocation-hook-functions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ typedef int (__cdecl * _CRT_ALLOC_HOOK)
(int, void *, size_t, int, long, const unsigned char *, int);
```

When the run-time library calls your hook, the *nAllocType* argument indicates what allocation operation is about to be made (**_HOOK_ALLOC**, **_HOOK_REALLOC**, or **_HOOK_FREE**). In a free or in a reallocation, `pvData` has a pointer to the user article of the block about to be freed. However for an allocation, this pointer is null, because the allocation hasn't occurred. The remaining arguments contain the size of the allocation in question, its block type, the sequential request number associated with it, and a pointer to the file name. If available, the arugments also include the line number in which the allocation was made. After the hook function performs whatever analysis and other tasks its author wants, it must return either **TRUE**, indicating that the allocation operation can continue, or **FALSE**, indicating that the operation should fail. A simple hook of this type might check the amount of memory allocated so far, and return **FALSE** if that amount exceeded a small limit. The application would then experience the kind of allocation errors that would normally occur only when available memory was very low. More complex hooks might keep track of allocation patterns, analyze memory use, or report when specific situations occur.
When the run-time library calls your hook, the *nAllocType* argument indicates what allocation operation is about to be made (**_HOOK_ALLOC**, **_HOOK_REALLOC**, or **_HOOK_FREE**). In a free or in a reallocation, `pvData` has a pointer to the user article of the block about to be freed. However for an allocation, this pointer is null, because the allocation hasn't occurred. The remaining arguments contain the size of the allocation in question, its block type, the sequential request number associated with it, and a pointer to the file name. If available, the arguments also include the line number in which the allocation was made. After the hook function performs whatever analysis and other tasks its author wants, it must return either **TRUE**, indicating that the allocation operation can continue, or **FALSE**, indicating that the operation should fail. A simple hook of this type might check the amount of memory allocated so far, and return **FALSE** if that amount exceeded a small limit. The application would then experience the kind of allocation errors that would normally occur only when available memory was very low. More complex hooks might keep track of allocation patterns, analyze memory use, or report when specific situations occur.

## See Also
[Allocation Hooks and C Run-Time Memory Allocations](../debugger/allocation-hooks-and-c-run-time-memory-allocations.md)
Expand Down