> Nullptr is needed in C++ because `0` is the only definition of `NULL` that works with the type system, due to the lack of implicit `void` conversions.*

> C doesn't have this problem.

Except for conversions between data pointers and function pointers ;)

Initialization seems to be a special case, but with `-pedantic` the following code will show a warning on the initialization of `fp2`:

    void* return_null() {
        return 0;
    }
    
    int main() {
        void(*fp1)() = 0;
        void(*fp2)() = return_null();
    
        return 0;
    }

POSIX requires this to be supported as well.

>C doesn't have this problem

I don't think a strong type system is a `problem`, implicit conversions can lead to so many annoying and hard to find bugs.

That's a fine general sentiment. However, in this context it's a problem if you want to assign NULL to a pointer without a cast, which is why C++ added the magically convertible nullptr in addition to the magically convertible `0` constant.

     char *x = 0; // ok in C and C++
     char *y = (void*)0; // ok in C, error in C++
     char *z = nullptr; // ok in C++

therefore:

     #define NULL ((void*)0) // Required by Posix C, invalid C++
     #define NULL 0 // Pre-nullptr, the only valid C++ definition

C++ can't define NULL the safe way that Posix C does.

I don't understand why it's more acceptable to allow magic `0` conversions than magic `(void*)0` conversions, given that the latter is far less likely to happen by accident -- but here we are.

> I don't understand why it's more acceptable to allow magic `0` conversions than magic `(void*)0` conversions

In the end you don't have to chose between '0' and 'nullptr' anyways.

    char *x = (decltype (nullptr)) 0;

They didn't say the type system is a problem, they said it caused a problem.

Case in point, integer arithmetic in C. Reasoning about types there is just tiring.

Give me a legitimate use for void* that isn't a conversion.