Re: undersized unions

Hi,

On February 5, 2023 6:16:55 AM GMT+01:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Michael Paquier <michael(at)paquier(dot)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 problems as-is.

On the one hand there's compiler optimizations that could end up being a problem - imagine two branches of an if allocating something containing a union and one assigning to 32 the other to a 64bit integer union member. It'd imo be reasonable for 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 unsafe to 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.