Thread: pgsql: Silence compiler warning on win32.

pgsql: Silence compiler warning on win32.

From
mha@postgresql.org (Magnus Hagander)
Date:
Log Message:
-----------
Silence compiler warning on win32.

ITAGAKI Takahiro

Modified Files:
--------------
    pgsql/src/test/regress:
        pg_regress.c (r1.57 -> r1.58)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.c?r1=1.57&r2=1.58)

Re: pgsql: Silence compiler warning on win32.

From
Tom Lane
Date:
mha@postgresql.org (Magnus Hagander) writes:
>     pgsql/src/test/regress:
>         pg_regress.c (r1.57 -> r1.58)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.c?r1=1.57&r2=1.58)

Surely this patch is wrong.  It is suppressing, not fixing, a critical
warning about a datatype mismatch.

            regards, tom lane

Re: pgsql: Silence compiler warning on win32.

From
Magnus Hagander
Date:
Tom Lane wrote:
> mha@postgresql.org (Magnus Hagander) writes:
>>     pgsql/src/test/regress:
>>         pg_regress.c (r1.57 -> r1.58)
>>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.c?r1=1.57&r2=1.58)
>
> Surely this patch is wrong.  It is suppressing, not fixing, a critical
> warning about a datatype mismatch.

You mean the signed vs unsigned part? Other than that, int and dword are
always the same on win32...

//Magnus


Re: pgsql: Silence compiler warning on win32.

From
Tom Lane
Date:
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Surely this patch is wrong.  It is suppressing, not fixing, a critical
>> warning about a datatype mismatch.

> You mean the signed vs unsigned part? Other than that, int and dword are
> always the same on win32...

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.  Just a couple weeks ago I wasted a great deal of time
finding a bug that was created by someone overriding this exact type of
compiler warning with a cast to something that *wasn't* binary
compatible.  (It worked fine on the author's machine, of course, but
not so much on one with a different sizeof long...)

            regards, tom lane