Piotr Stefaniak <postgres@piotr-stefaniak.me> writes:
>>> + myextra = (int *) malloc(sizeof(int));
> Please consider not casting malloc(). See
That code is per project style, and should stay that way.
> http://c-faq.com/malloc/mallocnocast.html
That argument is entirely bogus, as it considers only one possible way
in which the call could be wrong; a way that is of very low probability
in PG usage, since we include <stdlib.h> in our core headers. Besides
which, as noted in the page itself, most modern compilers would warn
anyway if you forgot the inclusion.
On the other side, coding with the explicit cast helps guard against far
more dangerous coding errors, which the compiler will *not* help you with.
What if myextra is actually of type "int64 *"? In that case you probably
meant to make enough space for an int64 not an int. But without the cast,
you won't be told you did anything wrong. This is a particular hazard if
you change your mind later on about the type of myextra. (A colleague
at Salesforce got burnt in exactly that way, just a couple days ago.)
So, general policy around here is that malloc and palloc calls should look
like
ptr = (foo *) malloc(n * sizeof(foo));
so that there's a direct, visible connection between the size calculation
and the type of the resulting pointer.
I'm aware that there are some places in the code that fail to do this,
but they are not models to emulate.
regards, tom lane
