Re: pgsql: Assume that we have signed integral types and flexible array mem

On Fri, Feb 21, 2020 at 2:52 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Why not just get rid of the FLEXIBLE_ARRAY_MEMBER hack altogether?
>
> As I said in the comment, I think it's good style.

I disagree. It doesn't seem important enough to make a fuss over, though.

> Even if you disagree, we shouldn't remove the macro, because that will
> just gratuitously break third-party code.

I'm not sure that it would be all that gratuitous myself. But I'd
be satisfied if we stopped using FLEXIBLE_ARRAY_MEMBER, while
leaving the symbol behind.

> I'm not 100% sure that aspect of the comment is still correct anyway.
> I just copied that advice from the Autoconf output --- but it might well
> be referring to the behavior of pre-C99 MSVC versions. However, if it
> is correct, why are you sure that violating the advice will lead to
> a compile error and not to silently-wrong size calculations?

I'm not sure of that, and should have been more careful in how I
worded my remarks. Still, blithely failing there would be an
incredibly user hostile thing for MSVC to do.

There is no reason to think that this "offsetof(struct s, f[0])" issue
is something that the FLEXIBLE_ARRAY_MEMBER hack was ever particularly
concerned with. At least, I have been aware of FLEXIBLE_ARRAY_MEMBER
but not aware of the possibly portability issue for years.
FLEXIBLE_ARRAY_MEMBER was introduced in 2011 to enable the use of C99
flexible arrays on compilers that supported it at the time.

--
Peter Geoghegan