Applied the change to master: rG57affc4e98ab: common,agent,dirmngr,kbx:w32: Synchronous spawning daemon process.

I checked the code under gnupg/dirmngr. Those are no harm.

I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.

For gpgrt/argparse this could be an option (to remove hard-coded /etc):

Fixed in 1.56.

Fixed with new GPGRT_PROCESS_STDIO_NUL flag.

Pushed the changes:

• Inheriting HANDLEs has been not working accurately
  • Before the fix, all HANDLEs were inherited
  • Only specified HANDLEs are inherited by: rE0b01950237ab: w32:spawn: Fix inheriting HANDLEs.
• HANDLEs by w32_open_null were leaked
  • fixed by: rEf28bf71b86ba: w32:spawn: Fix resource leaks for HANDLEs by w32_open_null.

T7723 fix by rE311fb769d1dd: w32:spawn: New flag GPGRT_PROCESS_STDIO_NUL.

Before implementing this feature, it's better to fix T7723: gpgrt:w32: Fix for inheriting stdin/stdout/stderr with "NUL", and do some clean up.

If we will fix gpgconf using GPGRT_PROCESS_STDIO_NUL, we will need to fix gpg-connect-agent to see if it's NUL or not.

Here is an experimental change to support the feature.

I looked at it but we probably need to rework/update the entire libtool stuff which has a high regression risk. Thus I give this bug a low priority because it is not a functional bug.

doc/HACKING says it's OK to use variadic arg macros (from C99 features).
If it's OK, this patch can fix the initialization (which silences GCC 15 warnings):

Note that 1.53 was released today which fixes a small regression: