Re: [COMMITTERS] pgsql: Silence compiler warning on win32.

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Silence compiler warning on win32.
Date: 2009-01-28 15:24:33
Message-ID: 498078B1.8060006@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Tom Lane wrote:
>>> Hmm, need more caffeine I guess. I was thinking dword == long. But in
>>> any case, I'd feel a lot more comfortable if the patch ifdef'd the
>>> declaration of exit_status to match, rather than forcing a cast of the
>>> pointer value.
>
>> Hmm. I looked at that, but that kind of just moves things around.
>
>> If i change that variable to be DWORD, it still stuffs it into
>> statuses[i] three lines further down,
>
> Sure, but that's a plain old assignment that can cope with the two
> variables being of different widths, so long as the value to be assigned
> fits in both. (And if it doesn't, I trust you'll agree that the code is
> broken...) Casting at the call is simply going to misbehave, very
> nastily, if somehow the variable isn't of the width the function is
> expecting.

Ok. Seems reasonble to change it to a cast in that place instead - will do.

>> I guess the proper solution in that case is to #define a datatype used
>> for return codes. Is it really worth that for this, though?
>
> Probably not, although I seem to recall we have done that elsewhere
> (pg_ctl maybe?)

Yeah, we have done it in one or two places. I'll just go with the cast
per above for this time.

//Magnus

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Magnus Hagander 2009-01-28 15:32:21 pgsql: Change warning-silencing code not to cast the pointer type,
Previous Message Tom Lane 2009-01-28 15:15:35 Re: [COMMITTERS] pgsql: Silence compiler warning on win32.

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-01-28 15:25:49 Re: Hot standby, recovery infra
Previous Message Magnus Hagander 2009-01-28 15:22:49 Re: mingw check hung