From: | Jacob Champion <pchampion(at)pivotal(dot)io> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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 15:30:21 |
Message-ID: | CABAq_6GXV-CppdZe9uHWPX3fHsE3+pQu-NzHGmBGM5tSfe5TiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 4, 2019 at 7:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
Why introduce a macro at all for the universal zero initializer, if it
seems to encourage the construction of other (incorrect) macros? IMO
the use of {0} as an initializer is well understood in the C developer
community, and I'm used to it showing up verbatim in code. Similar to
{}'s role as the C++ universal initializer.
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-10-04 15:33:08 | Re: Change atoi to strtol in same place |
Previous Message | Andres Freund | 2019-10-04 15:28:08 | Re: refactoring - share str2*int64 functions |