Re: Likely undefined behavior with some flexible arrays - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Likely undefined behavior with some flexible arrays
Date
Msg-id kgqxy33uzsbuwwgf3tr3f6ce52xny3bbfgz5rlotdlaftmumay@2vq6enbj63hx
Whole thread Raw
In response to Re: Likely undefined behavior with some flexible arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Likely undefined behavior with some flexible arrays
List pgsql-hackers
Hi,

On 2026-01-21 17:07:04 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I got a - I thought - spurious warning in a development patch. A simplified
> > reproducer of the warning is [1], which triggers:
> 
> > <source>: In function 'trigger_warning':
> > <source>:19:9: warning: array subscript 'struct foo[0]' is partly outside array bounds of 'unsigned char[13]'
[-Warray-bounds=]
> >    19 |     foop->len = len;
> >       |         ^~
> > <source>:18:12: note: object of size 13 allocated by 'allocme'
> >    18 |     foop = allocme(offsetof(struct foo, data) + sizeof(char) * len);
> >       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Compiler returned: 0
> 
> Considering that palloc() is going to round up the request to a
> maxalign boundary, I think the chances of actual trouble are
> precisely zero.

I am more worried about mis-optimizations than actually overflowing an
allocation or such. Although I guess we might eventually see things like
spurious valgrind overflow warnings, if the compiler decides to write to the
padding bytes for efficiency reasons.


> However, if we start getting such warnings on common compilers, maybe the
> way to fix it is to put the maxaligns into the calls?

The only reason we're not getting them widely right now is that we're
effectively hiding the allocation sizes from the compiler, because the
compiler doesn't currently know that palloc() allocates. It'd be nice to teach
the compile that palloc allocates, to a) get compiler warnings for things like
use-after-free b) warnings for things like access-beyond-allocation.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Remove no-op pull_var_clause flag
Next
From: Fujii Masao
Date:
Subject: Re: Flush some statistics within running transactions