Skip to content

Use C99 designated initialisers for PerlIO_funcs - #24390

Merged
leonerd merged 1 commit into
bleadfrom
perlio-designated-initialisers
Jul 16, 2026
Merged

Use C99 designated initialisers for PerlIO_funcs#24390
leonerd merged 1 commit into
bleadfrom
perlio-designated-initialisers

Conversation

@ilmari

@ilmari ilmari commented Apr 25, 2026

Copy link
Copy Markdown
Member

This avoids having to count NULLs for layers that only implement a subset of functions.


  • This set of changes does not require a perldelta entry.

This avoids having to count NULLs for layers that only implement a
subset of functions.
@Leont Leont added the defer-next-dev This PR should not be merged yet, but await the next development cycle label Apr 25, 2026
@tonycoz

tonycoz commented Apr 28, 2026

Copy link
Copy Markdown
Contributor

I think it is a silly warning with designated initializers, but g++ produces a mess of warnings:

g++ -c -DPERL_CORE -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -Wall -Werror=pointer-arith -Werror=vla -Wextra -Wno-long-long -Wno-nonnull-compare -Wwrite-strings -Wno-use-after-free perlio.c
perlio.c:1031:1: warning: missing initializer for member ‘_PerlIO_funcs::size’ [-Wmissing-field-initializers]
 1031 | };
      | ^
perlio.c:1031:1: warning: missing initializer for member ‘_PerlIO_funcs::Popped’ [-Wmissing-field-initializers]
perlio.c:1031:1: warning: missing initializer for member ‘_PerlIO_funcs::Binmode’ [-Wmissing-field-initializers]
perlio.c:1031:1: warning: missing initializer for member ‘_PerlIO_funcs::Getarg’ [-Wmissing-field-initializers]
... and many more

Adding C++ default initializers prevents the warnings but that would be a mess of macros for us.

I suspect the best choice would be to suppress the warning:

GCC_DIAG_IGNORE_DECL(-Wmissing-field-initializers);
PERLIO_FUNCS_DECL(PerlIO_remove) = {
     .fsize = sizeof(PerlIO_funcs),
    .name = "pop",
    .kind = PERLIO_K_DUMMY | PERLIO_K_UTF8,
    .Pushed = PerlIOPop_pushed,
    .Open = PerlIOBase_open,
};
GCC_DIAG_RESTORE

@leonerd

leonerd commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

I encountered this problem of the g++ warnings again recently in #24508, and discussed it out loud on the mailing list https://www.nntp.perl.org/group/perl.perl5.porters/2026/06/msg271009.html

While it is technically possible to silence the warnings by wrapping them as suggested, I would find this annoyingly verbose to have to remember to do for every C99-style struct initialisation we ever write into our code, just to quiet a warning in the tiny corner-case of us using g++ to compile a C program. I'm not going to veto it for this specific PR, but I am keen to look into finding a better solution to the overall problem, as I mentioned on the mailing list.

@ilmari

ilmari commented Jul 7, 2026

Copy link
Copy Markdown
Member Author

Would it work to wrap the suppression in a macro?

#define PERLIO_FUNCS_DEF(funcs, ...) \
    GCC_DIAG_IGNORE_DECL(-Wmissing-field-initializers); \
    PERLIO_FUNCS_DECL(funcs) = { __VA_ARGS__ };         \
    GCC_DIAG_RESTORE

and then do:

PERLIO_FUNCS_DEF(PerlIO_remove,
     .fsize = sizeof(PerlIO_funcs),
    .name = "pop",
    .kind = PERLIO_K_DUMMY | PERLIO_K_UTF8,
    .Pushed = PerlIOPop_pushed,
    .Open = PerlIOBase_open,
);

Ore even a generic STRUCT_INIT macro?

#define STRUC_INIT(decl, ...) \
    GCC_DIAG_IGNORE_DECL(-Wmissing-field-initializers); \
    decl = { __VA_ARGS__ };         \
    GCC_DIAG_RESTORE

@leonerd

leonerd commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

As the g++ warnings are a wider issue that affects a bunch of PRs and potential future code, and also is already an issue in blead right now, I've opened a separate issue #24553 to discuss it

@leonerd

leonerd commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Now that #24559 is in, this shouldn't cause upsets to g++

@leonerd
leonerd merged commit 62bc772 into blead Jul 16, 2026
68 checks passed
@leonerd leonerd removed the defer-next-dev This PR should not be merged yet, but await the next development cycle label Jul 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants