Hi,
On February 5, 2023 6:16:55 AM GMT+01:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Michael Paquier <michael@paquier.xyz> writes:
>> On Sat, Feb 04, 2023 at 05:07:08AM -0800, Andres Freund wrote:
>>> We actually have a fair amount of code like that, but currently are
>>> escaping most of the warnings, because gcc doesn't know that palloc() is
>>> an allocator. With more optimizations (particularly with LTO), we end up
>>> with more of such warnings. I'd like to annotate palloc so gcc
>>> understands the size, as that does help to catch bugs when confusing the
>>> type. It also helps static analyzers.
>
>> Ah, that seems like a good idea in the long run.
>
>I'm kind of skeptical about whether we'll be able to get rid of all
>the resulting warnings without extremely invasive (and ugly) changes.
It's not that many sources of warnings, fwiw.
But the concrete reason for posting here was that I'm wondering whether the "undersized" allocations could cause
problemsas-is.
On the one hand there's compiler optimizations that could end up being a problem - imagine two branches of an if
allocatingsomething containing a union and one assigning to 32 the other to a 64bit integer union member. It'd imo be
reasonablefor the compiler to move that register->memory move outside of the if.
On the other hand, it also just seems risky from a code writing perspective. It's not immediate obvious that it'd be
unsafeto create an on-stack Numeric by assigning *ptr. But it is.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.