Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Nelson <joe(at)begriffs(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays
Date: 2019-10-04 14:51:07
Message-ID: 11568.1570200667@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Nelson <joe(at)begriffs(dot)com> writes:
> One might argue that INIT_ALL_ELEMS_FALSE as a synonym for
> INIT_ALL_ELEMS_ZERO is good for readability in the same way that "false"
> is for 0. However I want to avoid creating the impression that there is,
> or can be, a collection of INIT_ALL_ELEMS_xxx macros invoking different
> initializer behavior.

I concur with Joe here. The reason why some of the existing
memset's use "false" is for symmetry with other places where we use
"memset(p, true, n)" to set an array of bools to all-true. That
coding is unfortunately a bit dubious --- it would sort-of fail if
bool weren't of width 1, in that the bools would still test as true
but they wouldn't contain the standard bit pattern for true.
I don't want to change those places, but we shouldn't make the
mechanism proposed by this patch look like it can do anything but
initialize to zeroes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-10-04 15:28:08 Re: refactoring - share str2*int64 functions
Previous Message Tom Lane 2019-10-04 14:43:18 Re: Memory Accounting