| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Tristan Partin <tristan(at)partin(dot)io>, Greg Burd <greg(at)burd(dot)me> |
| Subject: | Re: Add compiler option -fstrict-flex-arrays=1 |
| Date: | 2026-10-19 13:47:39 |
| Message-ID: | baff552d-4db1-49c3-a811-847295348b9f@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Peter!
> Ideally, we'd want to use the maximum level -fstrict-flex-arrays=3,
> which would only allow flexible array members declared with the C
> standard "[]". But we do need to permit flexible array members declared
> with "[1]" in a few cases because standard C does not allow flexible
> array members as the only element in a struct. Affected are:
>
> - struct RevmapContents
> - struct ReplicationSlotCtlData
> - union pgresult_data
>
> (Some of these have comments "It should be declared
> [FLEXIBLE_ARRAY_MEMBER], but for some reason you can't do that in an
> otherwise-empty struct.")
I think that's because sizeof any struct in C must be > 0. If a struct
contains no other member than an [] array, sizeof would be 0.
Can we maybe use typedefs instead of structs for the cases you
mentioned? At least it's valid C to write typedef char Foo[].
> There is also:
>
> - struct sqlda_struct
>
> which, as I understand it, is bound by external API specification, so
> not easy to change.
>
> If we turned on -fstrict-flex-arrays=3, these would become undefined
> behavior and trigger the ubsan sanitizer.
The compiler setting can be changed on a per-struct basis via
__attribute__((strict_flex_arrays(N)));
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Geier | 2026-10-19 13:57:47 | Re: Improving scalability of Parallel Bitmap Heap/Index Scan |
| Previous Message | Andrew Dunstan | 2026-10-19 13:36:55 | Re: Allow table AMs to define their own reloptions |