| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| 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-16 00:24:53 |
| Message-ID: | 14352.1292459093@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 06:42 PM, Tom Lane wrote:
>> Hm, where did you get this?
> I downloaded
> <http://softlayer.dl.sourceforge.net/project/mingw/MinGW/BaseSystem/RuntimeLibrary/MinGW-RT/mingwrt-3.18/mingwrt-3.18-mingw32-src.tar.gz>
> which is allegedly the source for the latest released runtime.
Huh, I wonder why it doesn't match what's in sourceforge CVS?
Anyway, the short answer is that this code has got no visible
commonality with glibc's getopt(), so we need not fear that what
it's doing is likely to start happening elsewhere. I didn't take
the time to trace through the glibc code exactly; I figure the lack
of trouble reports is sufficient proof that we're not doing anything
that it won't cope with.
So I concur with the previous suggestions:
1. Make this problem go away by forcing use of our getopt code on
mingw.
2. Make sure we reset optreset when using our code. (Probably not
really necessary, but let's just be careful.)
Should we backpatch either of these things?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-12-16 00:44:21 | Re: Complier warnings on mingw gcc 4.5.0 |
| Previous Message | Andrew Dunstan | 2010-12-16 00:09:06 | Re: Complier warnings on mingw gcc 4.5.0 |