@efiring @jkseppan blame says the two of you have worked on this bit of code before.

Looks correct to me.

As far as I understand C, there is nothing "unclean" about the existing version here; but the explicit casts don't hurt anything. (In my understanding, the point of having a void pointer is that explicit casts are not needed. Otherwise, to be consistent, you would also need to use a cast with every assignment of NULL.)
This seems like the wrong solution to the original problem, however, which is that there is a chunk of C++ marooned in a C source file (in qhull). Running everything through a C++ compiler seems like an odd hack.

I was wondering why the NULL doesn't need a cast, but I guess that expands to nullptr and is handled specially in C++.

Must be; but the basic point is that this is C code, not C++. And as C code, it doesn't need the explicit casts.

I agree that the casts are unnecessary when compiling as C, but if this file is otherwise valid as C++ I don't see the harm in adding the casts. I also agree that the proper fix is to make qhull valid C.

Yep, this did the trick! Is there a way to force the use of icpc in the build config? Otherwise I think the default build will fail, which includes installs from package managers like pip.

CC=icpc python setup.py install

Given that this change does no harm, I will merge it. But I also merged #4519, so it shouldn't be necessary unless someone really wants to force the compiler to be icpc.

@efiring Ah, learned something about C, I have mostly worked in C++.

@frenchwr The 'easy' cop out there is to install all the dependencies first.

So, it seems we have two ugly but functional solutions (this and #4519 ).

the `-fp-model strict' which I (maybe wrongly) translated to 'pointer model'

FYI, this refers to the floating point model (strict IEEE754, denormal handling, etc.)