Collected from the PG bugs email list.
Body of first available message related to this bug follows.
The following bug has been logged on the website: Bug reference: 16157 Logged by: cili Email address: (redacted) 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.
|2019-12-09 12:44:01+00||PG Bug reporting form||BUG #16157: handling of pg_malloc(0)|
|2019-12-09 15:19:27+00||Tom Lane||Re: BUG #16157: handling of pg_malloc(0)|
|2019-12-10 09:51:29+00||cilizili||Re: BUG #16157: handling of pg_malloc(0)|