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