Bug in pg_restore memory handling

I found a bug in the pg_restore code. It shows up only using the tar
format, and only on Windows XP (not Win2000 or BSD/OS). However, the
bug exists on all platforms that don't return zero'ed memory from
malloc, which is basically everyone. We have gotten away with this
because malloc memory is usually zeroed by accident in pg_dump (I think
because it is an early malloc call, not recycled from a free.)

The bug seems to only affect the output displayed by pg_restore --- the
data seems to restore fine. To test, try:

pg_dump -Ft test >/tmp/test.db
pg_dump /tmp/test.db

For a simple case, you should see displayed by pg_restore:

COPY supplier (sno, sname, city) FROM stdin;
1 Smith London
2 Jones Paris
3 Adams Vienna
4 Blake Roma
\.

But on XP with the bug I see:

COPY supplier (sno, sname, city) FROM stdin;
\.
copy supplier (sno, sname, city) from '$$PATH$$/6.dat' ;

The code in pg_backup_tar.c::InitArchiveFmt_Tar does:

ctx = (lclContext *) malloc(sizeof(lclContext));
AH->formatData = (void *) ctx;
ctx->filePos = 0;

What it doesn't do is to set ctx->isSpecialScript to zero:

ctx->isSpecialScript = 0;

pg_backup_tar::_PrintTocData() checks ctx->isSpecialScript for non-zero,
and then uses the wrong code path on XP. The code is supposed to use
the ctx->isSpecialScript code path only after the archive is closed.
This is set to true in _CloseArchive(). ctx->isSpecialScript is used
only for tar, so that's why only tar has the bug.

A simple patch would be to just add the ctx->isSpecialScript = 0, but a
more reliable patch would be to do that, plus change a few malloc calls
to calloc for complex structures where the initialization isn't clear in
the code.

I would like to apply the attached patch to 7.3.X and 7.4.

Comments?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073