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
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. |
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 |