Re: pgsql: Use FLEXIBLE_ARRAY_MEMBER in a bunch more places.

On 2015-02-20 05:12:00 +0000, Tom Lane wrote:
> Use FLEXIBLE_ARRAY_MEMBER in a bunch more places.
>
> Replace some bogus "x[1]" declarations with "x[FLEXIBLE_ARRAY_MEMBER]".
> Aside from being more self-documenting, this should help prevent bogus
> warnings from static code analyzers and perhaps compiler misoptimizations.
>
> This patch is just a down payment on eliminating the whole problem, but
> it gets rid of a lot of easy-to-fix cases.
>
> Note that the main problem with doing this is that one must no longer rely
> on computing sizeof(the containing struct), since the result would be
> compiler-dependent. Instead use offsetof(struct, lastfield). Autoconf
> also warns against spelling that offsetof(struct, lastfield[0]).
>
> Michael Paquier, review and additional fixes by me.

This triggers a large number of warnings with my preexisting clang 3.6 settings...

In file included from /home/andres/src/postgresql/src/backend/postmaster/pgstat.c:40:
/home/andres/src/postgresql/src/include/catalog/pg_proc.h:61:12: warning: 'proargtypes' may not be nested in a struct due to flexible array
member [-Wflexible-array-extensions]
oidvector proargtypes; /* parameter types (excludes OUT params) */
^
In file included from /home/andres/src/postgresql/src/backend/executor/execQual.c:40:
In file included from /home/andres/src/postgresql/src/include/access/nbtree.h:21:
/home/andres/src/postgresql/src/include/catalog/pg_index.h:48:13: warning: 'indkey' may not be nested in a struct due to flexible array
member [-Wflexible-array-extensions]
int2vector indkey; /* column numbers of indexed cols, or 0 */
and many more.

Now, -Wflexible-array-extensions is IIRC not a standard option and I
only got it because I use -Weverything and disable the crazy stuff. So
maybe it's not worth worrying about. I'll just include
-Wno-flexible-array-extensions for now.

But I thought it's worth mentioning that at least one person went
through the trouble of adding a warning about this ;). I can't really
agree in this case because indkey still is the, as far the compiler can
see, last element of a struct, even if there's nesting.

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services