Re: Remove MSVC scripts from the tree

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