From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jacob Champion <pchampion(at)pivotal(dot)io> |
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:49:13 |
Message-ID: | 14069.1570204153@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jacob Champion <pchampion(at)pivotal(dot)io> writes:
> 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.
> Why introduce a macro at all for the universal zero initializer, if it
> seems to encourage the construction of other (incorrect) macros?
Well, the argument is that some people might think that if {0} is enough
to set all array elements to 0, then maybe {1} sets them all to ones
(as, indeed, one could argue would be a far better specification than
what the C committee actually wrote). Using a separate macro and then
discouraging direct use of the incomplete-initializer syntax should help
to avoid that error.
> 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.
Yeah, if we were all 100% familiar with every sentence in the C standard,
we could argue like that. But we get lots of submissions from people
for whom C is not their main language. The fewer gotchas there are in
our agreed-on subset of C, the better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-10-04 16:19:06 | Re: How to retain lesser paths at add_path()? |
Previous Message | Tom Lane | 2019-10-04 15:41:36 | Re: Memory Accounting |