Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>
Subject: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors
Date: 2014-03-22 15:00:47
Message-ID: 18379.1395500447@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-22 15:04:02 Re: Partial index locks
Previous Message Andrzej Mazurkiewicz 2014-03-22 10:51:04 Re: Inheritance of foregn key constraints.