BUG #16157: handling of pg_malloc(0)

The following bug has been logged on the website:

Bug reference: 16157
Logged by: cili
Email address: cilizili(at)protonmail(dot)com
PostgreSQL version: 12.1
Operating system: CentOS 7.4
Description:

While checking code, I found a potential bug. To avoid unportable behavior
of malloc(0), pg_malloc family functions in fe_memutils.c replace the size 0
with 1. I think 1 is poor, any size of chunk enought for structure or
pointer may be required.
The pg_malloc() is used instead of malloc(), and the output is casted into
other types. For example, in initdb.c:L508, if nlines equals to 2^32-1,
result = (char **) pg_malloc((nlines + 1) * sizeof(char *));
will be
result = (char **) pg_malloc(0);
and, according to replacement with 1, it is equivalent to
result = (char **) malloc(1);
however, I think that the expected code may be, a size of pointer,
result = (char **) malloc(1 * sizeof(char *));

Of course, 2^32-1 lines of postgresq.conf.sample or others are too huge and
unlikely. Fortunately, when a huge file has been read, initdb will report
'out of memory' and safely stop.
In the previous case, pg_malloc0() is better than pg_malloc().

BTW, I can't find any real issue of pg_malloc(0). It a good news. However,
since many codes cast the outputs of pg_malloc, palloc, and other allocation
functions, I consider that the replacement of the size for 0 in pg_malloc()
should be more large value enought to store any type of structure. For
example, if pg_malloc(0) is treated as malloc(1024), it my avoid previous
small allocation problems.