Re: Complier warnings on mingw gcc 4.5.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Complier warnings on mingw gcc 4.5.0
Date: 2010-12-15 16:43:02
Message-ID: 7459.1292431382@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 12/15/2010 11:12 AM, Tom Lane wrote:
>> 1. Is that build using src/port/getopt.c, or a library-supplied getopt?
>> What about getopt_long.c?
>>
>> 2. Is HAVE_INT_OPTRESET getting defined? Should it be?

> I had the same thought. I did try forcing use of our getopt and
> getopt_long, without success, but didn't look at optreset.

Do we use configure at all on a mingw build? If we don't, then
HAVE_INT_OPTRESET is surely not getting defined.

It looks to me like it might be a good idea to force HAVE_INT_OPTRESET
on when we are using our own versions of getopt/getopt_long. If we
don't set that, then correct behavior depends on the assumption that the
internal variable "place" is pointing at a null when the second series
of getopt calls starts. While I'm prepared to believe that the last
call of getopt left it that way, it's not clear that we can safely
assume that the underlying argv array hasn't been clobbered meanwhile.

You might try adding some debug printouts to src/port/getopt.c to see if
you can trace exactly what's happening there.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-12-15 16:45:28 Re: Complier warnings on mingw gcc 4.5.0
Previous Message Robert Haas 2010-12-15 16:34:59 Re: ALTER TABLE ... REPLACE WITH