Re: Complier warnings on mingw gcc 4.5.0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Complier warnings on mingw gcc 4.5.0
Date
Msg-id 7459.1292431382@sss.pgh.pa.us
Whole thread Raw
In response to Re: Complier warnings on mingw gcc 4.5.0  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Complier warnings on mingw gcc 4.5.0  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: ALTER TABLE ... REPLACE WITH
Next
From: Magnus Hagander
Date:
Subject: Re: Complier warnings on mingw gcc 4.5.0