Piotr Stefaniak <postg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
