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

From: "Joe Nelson" <joe(at)begriffs(dot)com>
To: "Stephen Frost" <sfrost(at)snowman(dot)net>, "Andres Freund" <andres(at)anarazel(dot)de>
Cc: "Chapman Flack" <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays
Date: 2019-10-21 15:25:57
Message-ID: e50d0213-6e59-4325-8e75-8b46bf4b3bc5@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I don't understand why this is an issue worth deviating from the
> > standard for.
>
> Because this use and the way the standard is defined in this case is
> confusing and could lead later hackers to misunderstand what's going on
> and end up creating bugs-

The two possible misunderstandings seem to be:

1. how 0 is interpreted in various contexts such as bool
2. that the x in {x} applies to only the first element

IMHO we should expect people to be familiar with (1), and we have the
INIT_ALL_ELEMS_ZERO macro to avoid (2). However the more I look at the
code using that macro the less I like it. The {0} initializer is more
idiomatic.

My vote would be to use {0} everywhere and avoid constructions like
{false} which might exacerbate misunderstanding (2).

> I figured it was common knowledge that gcc/clang supported it just fine,
> which covers something like 90% of the buildfarm. I haven't got easy
> access to check others.

As Amit pointed out, {} doesn't work with MSVC-2017, nor is there any
reason it should, given that it isn't part of the C standard.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2019-10-21 15:40:44 Re: jsonb_set() strictness considered harmful to data
Previous Message Andres Freund 2019-10-21 15:20:04 Re: Declaring a strict function returns not null / eval speed