Hi, On 2023-12-07 12:33:35 +0100, Alvaro Herrera wrote: > Well, We have things like these > > typedef struct _archiveOpts > { > ... > } ArchiveOpts; > #define ARCHIVE_OPTS(...) &(ArchiveOpts){__VA_ARGS__} > > XL_ROUTINE is quite similar. > > These are then used like > ARCHIVE_OPTS(.tag = "pg_largeobject", > .description = "pg_largeobject", > .section = SECTION_PRE_DATA, > .createStmt = loOutQry->data)); > > so the difference is that we're passing a pointer to a struct, not > the struct bare, which is what c99_test is doing: > > struct named_init_test { > int a; > int b; > }; > > int main() { > ... > structfunc((struct named_init_test){1, 0}); > } > > Maybe this would work if the function received the pointer too? > > extern void structfunc(struct named_init_test *); > > structfunc(&(struct named_init_test){1, 0}); > > The fact that this is called "structfunc" makes me wonder if the author > did indeed want to test passing a struct to the function. That'd be > odd, since the interesting thing in this line is the expression used to > initialize the struct argument. (We do pass structs, eg. ObjectAddress > to check_object_ownership; old code.)
It seems like both might be interesting? But I think there's no reason to not evolve this test if we need to. I think I wrote it testing with a few old *nix compilers to see where -std=c99 was needed, not more. It's not too surprising that it might need some massaging for older msvc... However: I used godbolt to compile the test code on msvc, and it seems to build with 19.15 (which is the version Andrew referenced upthread), with a warning that's triggered independent of the structfunc bit. https://godbolt.org/z/j99E9MeEK Andrew, could you attach meson.log from the failed build? Greetings, Andres Freund