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
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 |