Replaced 0 with PUGIXML_NULL when a nullptr would have been needed.

[PhilipBotha]

Fixed a GCC warning about using a const literal zero in place of nullptr (-Wzero-as-null-pointer-constant) by using the already defined PUGIXML_NULL macro when the C++ version supports nullptr.

[zeux]

Just want to check - does using NULL instead of PUGIXML_NULL in pugixml.cpp also silence the warnings?

The reason to prefer NULL in this case is that since pugixml isn't a C++11 codebase, and 0 vs nullptr have different semantics in certain cases for overloads, it would be a little safer for future changes to use NULL internally. We use PUGIXML_NULL in the external interface to ensure maximum compliance vs aggressive analysis tools like clang-tidy but I'm wondering if this is necessary in the implementation.

[zeux]

If this PR switches to NULL + has no unrelated whitespace changes I'd be happy to merge this.

[PhilipBotha]

Using NULL does fix the issue with GCC but Clang still complains :

warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]

So to keep it compatible with C++ from before C++11, PUGIXML_NULL is the better solution.

[zeux]

Using NULL does fix the issue with GCC but Clang still complains

That is unfortunate :-/ gcc explicitly silences this for NULL, https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=752e7593b0f19af233a0b7e72daab8413662b605, but it looks like clang version was implemented before this change was in effect, and never relaxed.

NULL felt like a straightforward fix but PUGIXML_NULL is significantly noisier, and we can't use nullptr because pre-C++11 support is important :-/ I'm now considering possibly silencing this diagnostic for clang in the source file via pragmas.

[zeux]

I'm going to merge this as is for now; we'll see if clang revisits the gcc compatibility (in which case we could enable the warning on clang depending on the version), but this definitely provides the readability improvements that the warning was intended to carry without sacrificing anything.