Thread

  1. Re: BUG #19343: toast_internals.c:139:2: warning: missing braces around initializer [-Wmissing-braces]

    Heikki Linnakangas <hlinnaka@iki.fi> — 2025-12-03T09:13:32Z

    On 02/12/2025 21:41, PG Bug reporting form wrote:
    > The following bug has been logged on the website:
    `>
    > Bug reference:      19343
    > Logged by:          Natalie Reno
    > Email address:      natalie.reno@cchmc.org
    > PostgreSQL version: 16.11
    > Operating system:   RHEL7
    > Description:
    > 
    > When compiling the latest version, 16.11, I received the following error:
    > gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith
    > -Wdeclaration-after-statement -Werror=vla -Wendif-labels
    > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
    > -fexcess-precision=standard -O2 -I../../../../src/include -D_GNU_SOURCE
    > -c -o toast_internals.o toast_internals.c
    > toast_internals.c: In function ‘toast_save_datum’:
    > toast_internals.c:139:2: warning: missing braces around initializer
    > [-Wmissing-braces]
    >    }   chunk_data = {0}; /* silence compiler warning */
    >    ^
    > toast_internals.c:139:2: warning: (near initialization for ‘chunk_data.hdr’)
    > [-Wmissing-braces]
    > 
    > When I compared toast_internals.c files between 16.11 and 16.10, I found
    > this difference that is supposed to account for silencing the compiler
    > warning.
    > 
    > diff
    > /u01/app/postgres/product/postgresql-16.11/src/backend/access/common/toast_internals.c
    > /u01/app/postgres/product/postgresql-16.10/src/backend/access/common/toast_internals.c
    > 139c139
    > <       }                       chunk_data = {0};       /* silence compiler
    > warning */ <-- 16.11
    > ---
    >>        }                       chunk_data; <-- 16.10
    
    On 'master', this was done slightly differently, see commit 748caa9dcb. 
    Peter decided to only do that bigger code rearrangement on 'master', and 
    do the less invasive initialization on backbranches [1]. I think we 
    should just backpatch the bigger code rearrangement too.
    
    [1] 
    https://www.postgresql.org/message-id/76f41fdc-69e1-43b4-b9aa-503b07980de1%40eisentraut.org
    
    - Heikki