Thread: pid_t on mingw

I wanted to propose the attached patch to get rid of the custom pgpid_t 
typedef in pg_ctl.  Since we liberally use pid_t elsewhere, this seemed 
plausible.

However, this patch fails the CompilerWarnings job on Cirrus, because 
apparently under mingw, pid_t is "volatile long long int", so all the 
printf placeholders mismatch.  However, we print pid_t as %d in a lot of 
other places, so I'm confused why this fails here.

Also, googling around a bit about this, it seems that mingw might have 
changed the pid_t from long long int to int some time ago.  Maybe that's 
how the pgpid_t came about to begin with.  The Cirrus job uses a 
cross-compilation environment.  I wonder how up to date that is compared 
to say the native mingw installations used on the build farm.

Any clues?

On 04.10.22 10:15, Peter Eisentraut wrote:
> I wanted to propose the attached patch to get rid of the custom pgpid_t 
> typedef in pg_ctl.  Since we liberally use pid_t elsewhere, this seemed 
> plausible.
> 
> However, this patch fails the CompilerWarnings job on Cirrus, because 
> apparently under mingw, pid_t is "volatile long long int", so all the 
> printf placeholders mismatch.  However, we print pid_t as %d in a lot of 
> other places, so I'm confused why this fails here.

I figured out that in most places we actually store PIDs in int, and in 
the cases where we use pid_t, casts before printing are indeed used and 
necessary.  So nevermind that.

In any case, I took this opportunity to standardize the printing of PIDs 
as %d.  There were a few stragglers.

And then the original patch to get rid of pgpid_t in pg_ctl, now updated 
with the correct casts for printing.  I confirmed that this now passes 
the CompilerWarnings job.