null pointer dereference occurs in Chapter 1 - Safe String Functions - 1st example

[shalala66]

In this section is located demo code example which demonstrates the reliability of security level of newer string functions in comparison with other classic string functions:

void wmain(int argc, const wchar_t* argv[])
{
    // assume arc >= 2 for this demo
    
    WCHAR buffer[32];
    wcscpy_s(buffer, argv[1]);       // C++ version aware of static buffers
    
    WCHAR* buffer2 = (WCHAR*)malloc(32 * sizeof(WCHAR));
    // wcscpy_s(buffer, argv[1]);         // does not compile 
    wcscpy_s(buffer2, 32, argv[1]);          // size in characters (not bytes)
    
    free(buffer2);
}

But I've noticed that in dynamic memory allocation part arises 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 value of buffer2", since buffer2 is the argument of wcscpy_s and due to SAL for wcscpy_s function the buffer2 can not be NULL related with "Warning C6011" where it took its initial point which corresponds to "null pointer dereferencing":

// corecrt_wstring.h
_Check_return_wat_
_ACRTIMP errno_t __cdecl wcscpy_s(
    _Out_writes_z_(_SizeInWords) wchar_t* _Destination,
    _In_ rsize_t _SizeInWords,
    _In_z_ wchar_t const* _Source
    );

// sal.h
#define _Out_writes_z_(size)                   _SAL2_Source_(_Out_writes_z_, (size), _Pre_cap_(size)            _Post_valid_impl_ _Post_z_)

This part is just about informational purposes for the other readers:
0x00000000 - 0x00000FFF in x86_32 and 0x0000000000000000 - 0x000000000000FFFF in x86_64: In Windows 9x architecture this region of memory for user level was not available for accessing from user mode because of though it's part of user mode region, but it's reserved by OS and played a trap role to detect a null pointers, plus to it contains the null address. Although they are have the close meaning in Windows NT architecture this region is for detection the pointers with wrong values. Trying to access this memory section causes to raising a "memory access violation" exeption. In this case null pointer must be store the value which indicates the fault and serves that this pointer is invalid. That is the target of reservation the null address by the system and of course this is the null pointer related section. But this region is not only included null address. Following the null address, are located the 65535 addresses. That is why the size of this region is 64KiB. It happens due to "data alignment" within comply the sophisticated rules to treatment all addresses with the same way. Despite to it's non-optimize, to deny access to some of addresses all 65536 addresses should to be denied, but this is small amount of memory in compairing with large total amount of user level memory. Null pointer dereferencing may causes a lot of problems started from large or small amount of memory corruptions associated even with compiler optimizations which according to the compiler the nullptr can not be dereferenced and could apply swapping of assignments which causes the "structural exception", but it will happen too late and despite this fact the datas in memory will be corrupted. That is why applying SEH (-> VEH) is not a single option at some in this case. Kindred situations related with compiler optimizations applying swap in assignments could be arises with the use of memset function also. I suggest make this kind of changes due to on my opinion this code snippet will be more secure hence clear in versions like below:

// 1st modificated version

#include "pch.h"

void wmain(int argc, const wchar_t* argv[])
{
    WCHAR buffer[32] = {'\0'};
    wcscpy_s(buffer, argv[1]);
    
    WCHAR* buffer2 = (WCHAR*)malloc(32 * sizeof(WCHAR));
    if (buffer2){
        memset(buffer2, 0, sizeof(WCHAR));
        wcscpy_s(buffer2, 32, argv[1]);
        free(buffer2);
    }
}

// 2nd modificated version

#include "pch.h"

void wmain(int argc, const wchar_t* argv[])
{
    WCHAR buffer[32] = {'\0'};
    wcscpy_s(buffer, argv[1]);
    
    WCHAR* buffer2 = (WCHAR*)calloc(32, sizeof(WCHAR));
    if (buffer2){
        wcscpy_s(buffer2, 32, argv[1]);
        free(buffer2);
    }
}