Thread: Combinations of pg_strdup/free in pg_dump code

Hi all,

While reading some code of pg_dump, I noticed that the following
pattern is heavily present:       lanname = pg_strdup(stuff)       free(lanname);

One example is for example that:       lanname = get_language_name(fout, transforminfo[i].trflang);       if (typeInfo
&&lanname)           appendPQExpBuffer(&namebuf, "%s %s",                             typeInfo->dobj.name, lanname);
  transforminfo[i].dobj.name = namebuf.data;       free(lanname);
 
And get_language_name() uses pg_strdup() to allocate the string freed here.

When pg_strdup or any pg-related allocation routines are called, I
think that we should use pg_free() and not free(). It does not matter
much in practice because pg_free() calls actually free() and the
latter per the POSIX spec should do nothing if the input pointer is
NULL (some version of SunOS that crash on that actually :p), but we
really had better be consistent in the calls done. Thoughts?
-- 
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
> While reading some code of pg_dump, I noticed that the following
> pattern is heavily present:
>         lanname = pg_strdup(stuff)
>         free(lanname);

> When pg_strdup or any pg-related allocation routines are called, I
> think that we should use pg_free() and not free(). It does not matter
> much in practice because pg_free() calls actually free() and the
> latter per the POSIX spec should do nothing if the input pointer is
> NULL (some version of SunOS that crash on that actually :p), but we
> really had better be consistent in the calls done. Thoughts?

I do not think this is worth troubling over, really.  If there are
places that are relying on free(NULL) to work, it might be worth
ensuring they go through pg_free; but the pattern you show here
is perfectly safe.  We have other things to do besides create
code churn for this.
        regards, tom lane