Re: Complier warnings on mingw gcc 4.5.0

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, 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 21:20:06
Message-ID: 4D093106.1020508@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/15/2010 03:52 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> And here is where it changed:
>> <http://sourceforge.net/project/shownotes.php?release_id=24832>
>> * A replacement implementation for the getopt() family of functions,
>> adding support for the GNU getopt_long_only() function. Users
>> should note that this intentionally *removes* support for the BSD
>> or Mac OS-X specific, and non-standard, `optreset' global variable;
>> to reset the getopt() scanner, use `optind = 0;' instead of relying
>> on this non-standard, non-portable and now-unsupported feature.
> Great. So instead of a nonstandard but pretty portable API, they
> decided on a nonstandard interpretation of optind ... which absolutely
> will not work for our usage, because we need to be able to tell getopt
> to skip over --single, even if we were willing to figure out whether
> getopt behaves this way or the more usual way. Dolts.
>
> While I don't mind forcing use of our getopt() on mingw, I'm a mite
> concerned by the idea that this might represent an upstream change we'll
> soon see elsewhere, rather than just mingw-specific brain damage.
> Anybody know?
>
>

On my Fedora box, man 3 getopt says this:

A program that scans multiple argument vectors, or rescans the same
vector more than once, and wants to make use of GNU extensions such
as '+' and '-' at the start of optstring, or changes the value of
POSIXLY_CORRECT between scans, must reinitialize getopt() by
resetting optind to 0, rather than the traditional value of 1.
(Resetting to 0 forces the invocation of an internal initialization
routine that rechecks POSIXLY_CORRECT and checks for GNU extensions
in optstring.)

Modulo the --single issue, we don't have to force use of our getopt on
Mingw. This patch seems to work, at least to get regression working:

diff --git a/src/backend/postmaster/postmaster.c
b/src/backend/postmaster/postmaster.c
index 90854f4..9ae3767 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -753,6 +753,8 @@ PostmasterMain(int argc, char *argv[])
optind = 1;
#ifdef HAVE_INT_OPTRESET
optreset = 1; /* some systems need this too */
+#elsif defined (WIN32) && !defined(_MSC_VER)
+ optind = 0; /* modern Mingw needs this instead */
#endif

/* For debugging: display postmaster environment */
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index ff2e9bd..ea4ae79 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3444,6 +3444,8 @@ process_postgres_switches(int argc, char
*argv[], GucContext ctx)
optind = 1;
#ifdef HAVE_INT_OPTRESET
optreset = 1; /* some systems need this too */
+#elsif defined (WIN32) && !defined(_MSC_VER)
+ optind = 0; /* modern Mingw
needs this instead */
#endif

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-15 21:26:26 Re: Complier warnings on mingw gcc 4.5.0
Previous Message Tom Lane 2010-12-15 20:52:03 Re: Complier warnings on mingw gcc 4.5.0