Skip to content

Update assert-asserte-assert-expr-macros.md#4850

Closed
shalala66 wants to merge 1 commit into
MicrosoftDocs:mainfrom
shalala66:patch-2
Closed

Update assert-asserte-assert-expr-macros.md#4850
shalala66 wants to merge 1 commit into
MicrosoftDocs:mainfrom
shalala66:patch-2

Conversation

@shalala66
Copy link
Copy Markdown
Contributor

  1. In dynamic memory allocation parts arise the "null pointer dereferencing" which can cause to undefined behaviour later. The first appeal to the memory by null pointer or in a differ terms dereferencing the null pointer usually causes the "structured exception" in Windows systems. In "Microsoft Visual Studio Community 2019 Version 16.11.29" environment compiler generates "Warning C6387" coherented with "NULL values of p1, p2", since p1, p2 are separately the arguments of strcpy_s and due to SAL for strcpy_s function the p1, p2 can not be NULL which maybe related indirectly with "Warning C6011" where it took its initial point which corresponds to "null pointer dereferencing":
// string.h
_Check_return_wat_
_ACRTIMP errno_t __cdecl strcpy_s(
        _Out_writes_z_(_SizeInBytes) char*       _Destination,
        _In_                         rsize_t     _SizeInBytes,
        _In_z_                       char const* _Source
        );

P.S.: if statements could be replaced respectively with:

 _ASSERT(p1 != NULL);
 _ASSERT(p2 != NULL); 

  1. Initialized the pointers to NULL.
    P.S.: In C23 it could be initialized as nullptr:
char *p1{nullptr};
char* p2{nullptr};

https://en.cppreference.com/w/c/compiler_support/23#:~:text=13-,nullptr,-N3042

1) In dynamic memory allocation parts arise the "null pointer dereferencing" which can cause to undefined behaviour later. The first appeal to the memory by null pointer or in a differ terms dereferencing the null pointer usually causes the "structured exception" in Windows systems. In "Microsoft Visual Studio Community 2019 Version 16.11.29" environment compiler generates "Warning C6387" coherented with "NULL values of p1, p2", since p1, p2 are separately the arguments of strcpy_s and due to SAL for strcpy_s function the p1, p2 can not be NULL which maybe related indirectly with "Warning C6011" where it took its initial point which corresponds to "null pointer dereferencing":

// string.h
_Check_return_wat_
_ACRTIMP errno_t __cdecl strcpy_s(
        _Out_writes_z_(_SizeInBytes) char*       _Destination,
        _In_                         rsize_t     _SizeInBytes,
        _In_z_                       char const* _Source
        );

P.S.: if statements could be replaced respectively with:
 _ASSERT(p1 != NULL);
 _ASSERT(p2 != NULL); 

2) Initialized the pointers to NULL;
@prmerger-automator
Copy link
Copy Markdown
Contributor

@shalala66 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@learn-build-service-prod
Copy link
Copy Markdown
Contributor

Learn Build status updates of commit b8f8f07:

✅ Validation status: passed

File Status Preview URL Details
docs/c-runtime-library/reference/assert-asserte-assert-expr-macros.md ✅Succeeded

For more details, please refer to the build report.

For any questions, please:

@TylerMSFT
Copy link
Copy Markdown
Collaborator

Hi, @shalala66. Thank you for taking an interest in the docs.
You are correct about how to handle the allocations. Our sample code isn't meant to be production ready code but rather to demo something specific about the topic. We often leave off the error handling because it obscures the point that the article is trying to make. It's not meant to be a production piece of code, but to demonstrate assert. It's also unnecessary to set the pointers to NULL first as they will be set to that if the allocation fails.
I think I'm going to skip on this one because the goal is to get as quickly as possible to the little sample that demos assert.
Take care and I hope the remainder of the year treats you well.

@TylerMSFT TylerMSFT closed this Dec 11, 2023
@shalala66
Copy link
Copy Markdown
Contributor Author

Hi, @TylerMSFT. These commits are about good practice even in demo code. This entire code snippet is not correct. Pointer initialization is also important in the all cases. It's potential wild pointer which is a uninitialized pointer till its first use hence by default it then hold some arbitrary memory location, and attempting to do any operation using it could be cause to crash of program. People learn from this platform and accepted this place as serious, since this site by Microsoft, but You ignore the necessary changings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants