Horton

Thread

Commits

  1. Fix compiler warnings around _CRT_glob

  2. Inhibit mingw CRT's auto-globbing of command line arguments

  1. _CRT_glob stuff

    Peter Eisentraut <peter@eisentraut.org> — 2025-09-18T10:02:58Z

    When you compile on Windows with a sufficiently new gcc or clang you'll 
get errors or warnings like this:

../src/common/exec.c:49:17: error: '_CRT_glob' initialized and declared 
'extern' [-Werror]
    49 | extern int      _CRT_glob = 0;          /* 0 turns off 
globbing; 1 turns it on */

or

../src/common/exec.c:49:12: error: 'extern' variable has an initializer 
[-Werror,-Wextern-initializer]
    49 | extern int      _CRT_glob = 0;          /* 0 turns off 
globbing; 1 turns it on */
       |                 ^
../src/common/exec.c:49:12: error: no previous extern declaration for 
non-static variable '_CRT_glob' [-Werror,-Wmissing-variable-declarations]
../src/common/exec.c:49:8: note: declare 'static' if the variable is not 
intended to be used outside of this translation unit
    49 | extern int      _CRT_glob = 0;          /* 0 turns off 
globbing; 1 turns it on */
       |        ^

(You can test this out on non-Windows by disabling the #if around it in 
src/common/exec.c.)

It took me a bit of research to figure out what

     extern int foo = 0;

even means.  It turns out that the "extern" is ignored in that case.  So 
I suggest we remove it from the code, to eliminate the confusion and the 
warnings.  And then we have to add in a real extern declaration (without 
initializer) to satisfy -Wmissing-variable-declarations.  So it should 
look like

diff --git a/src/common/exec.c b/src/common/exec.c
index 8b690a10185..cca89f04074 100644
--- a/src/common/exec.c
+++ b/src/common/exec.c
@@ -46,7 +46,8 @@

  /* Inhibit mingw CRT's auto-globbing of command line arguments */
  #if defined(WIN32) && !defined(_MSC_VER)
-extern int _CRT_glob = 0;      /* 0 turns off globbing; 1 turns it on */
+extern int _CRT_glob;
+int            _CRT_glob = 0;      /* 0 turns off globbing; 1 turns it 
on */
  #endif

  /*

Here is some relevant documentation that suggests that this is the 
correct approach:

https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/_mingw.h.in#L476

This also says that the default is 0 anyway, so it's not clear whether 
this is even useful anymore.  The commit that introduced this (commit 
b787c554c26) is from 2022, so it's not that long ago.  (It appears to be 
some old mingw vs. new mingw issue?)

  2. Re: _CRT_glob stuff

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-09-18T15:15:30Z

    On Thu, Sep 18, 2025 at 3:03 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> Here is some relevant documentation that suggests that this is the
> correct approach:
>
> https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/_mingw.h.in#L476
>
> This also says that the default is 0 anyway, so it's not clear whether
> this is even useful anymore.  The commit that introduced this (commit
> b787c554c26) is from 2022, so it's not that long ago.  (It appears to be
> some old mingw vs. new mingw issue?)

So if MinGW already defines its own version of this symbol [1], how
does this work in practice? Would it actually do anything if we
assigned -1 instead?

--Jacob

[1] https://github.com/mingw-w64/mingw-w64/blob/8181947c/mingw-w64-crt/crt/wildcard.c

  3. Re: _CRT_glob stuff

    Peter Eisentraut <peter@eisentraut.org> — 2025-09-19T07:37:46Z

    On 18.09.25 17:15, Jacob Champion wrote:
> On Thu, Sep 18, 2025 at 3:03 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>> Here is some relevant documentation that suggests that this is the
>> correct approach:
>>
>> https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/_mingw.h.in#L476
>>
>> This also says that the default is 0 anyway, so it's not clear whether
>> this is even useful anymore.  The commit that introduced this (commit
>> b787c554c26) is from 2022, so it's not that long ago.  (It appears to be
>> some old mingw vs. new mingw issue?)
> 
> So if MinGW already defines its own version of this symbol [1], how
> does this work in practice? Would it actually do anything if we
> assigned -1 instead?

Yes, if you do that, the pg_amcheck test 'schema exclusion pattern 
overrides all inclusion patterns' fails, which has an entirely plausible 
causality.

As to how it works, I'm not sure, but I suppose the linker somehow 
arranges the initializations in the right order.

  4. Re: _CRT_glob stuff

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-09-22T15:46:22Z

    On Fri, Sep 19, 2025 at 12:37 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> As to how it works, I'm not sure, but I suppose the linker somehow
> arranges the initializations in the right order.

Okay. I was a bit concerned that, if libpq pulled in this symbol via
pgcommon, it might accidentally affect the client executable... but I
guess our exports files are saving us there, and in any case the
executable's symbol (if defined) should win anyway. Carry on :)

--Jacob

  5. Re: _CRT_glob stuff

    Peter Eisentraut <peter@eisentraut.org> — 2025-10-01T15:19:56Z

    On 18.09.25 12:02, Peter Eisentraut wrote:
> So it should look like
> 
> diff --git a/src/common/exec.c b/src/common/exec.c
> index 8b690a10185..cca89f04074 100644
> --- a/src/common/exec.c
> +++ b/src/common/exec.c
> @@ -46,7 +46,8 @@
> 
>   /* Inhibit mingw CRT's auto-globbing of command line arguments */
>   #if defined(WIN32) && !defined(_MSC_VER)
> -extern int _CRT_glob = 0;      /* 0 turns off globbing; 1 turns it on */
> +extern int _CRT_glob;
> +int            _CRT_glob = 0;      /* 0 turns off globbing; 1 turns it 
> on */
>   #endif
> 
>   /*

I have committed this.