Fix NULL conversion warnings found in Alpine x64 Source-Build

[jkoritzinsky]

Fixes dotnet/source-build#4298

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[mangod9]

I worry that this kind of change reduces code readability? Are these new warnings related to a tooling update?

[jkoritzinsky]

With a more recent musl libc (the version in Alpine 3.19), NULL is defined as nullptr directly, making what was suppressable warnings with our current toolsets into unsupressable compiler errors. This PR includes fixes for all the locations that were now procuding errors for an x64 build on Alpine 3.19 (what the source-build pipeline tests).

In the future, I plan to follow up with re-enabling the warnings and fixing the remaining cases

[mangod9]

so is there no way to #ifdef NULL to 0 somehow for this platform?

cc: @AaronRobinsonMSFT @janvorli

[janvorli]

This PR uses (UINT_PTR)NULL instead of 0 in a similar case, it seems like it would be better here too.

[janvorli]

Here it would be actually (INT_PTR)NULL

[jkoritzinsky]

Okay this PR has now included all of the various different changes to handle the three different definitions of NULL that the standard libraries we build against use (and how they interact with our DAC-ized pointer types).

• #define NULL nullptr as used by newer versions of musl libc (Alpine 3.19)
• #define NULL __null as used by glibc (GCC/Clang)
• #define NULL 0 as used by MSVC

This generally involved changing code like TADDR foo = NULL to TADDR foo = (TADDR)NULL or TADDR foo = 0 and changing PTR_Bar foo = NULL to PTR_Bar foo = nullptr.

[jkoritzinsky]

I've taken a different approach here that should still work and cut the diff in half (and removed the majority of the changes required for non Alpine).

[janvorli]

LGTM, thank you!

[AaronRobinsonMSFT]

One suggestion and a few nits to consider. Thanks!