Thread: PATCH for pgconnection.h
I am using the Sun Workshop C 5.0, noticed that I was getting the
following errors:
"pgconnection.h", line 65: Error: string is not defined.
"pgconnection.cc", line 134: Error: string is not defined.
"pgconnection.cc", line 139: Error: Cannot return char* from a function
that should return int.
3 Error(s) detected.
Futher looking noticed that the standard namespace was not being used
for the "string" typedef, so the following patch fixed that for me.
This is for the 6.5 tar release & the 6/24 CVS checkout.
vlad: diff -w3c interfaces/libpq++/pgconnection.h.orig
interfaces/libpq++/pgconnection.h
*** interfaces/libpq++/pgconnection.h.orig Thu Jun 24 10:49:54 1999
--- interfaces/libpq++/pgconnection.h Thu Jun 24 10:48:31 1999
***************
*** 23,28 ****
--- 23,34 ---- #include <stdio.h> #include <string>
+ #ifdef __sun__
+ #ifndef __GNUC__
+ using namespace std;
+ #endif
+ #endif
+ extern "C" { #include "libpq-fe.h" }
--
Brian Millett
Enterprise Consulting Group "Heaven can not exist,
(314) 205-9030 If the family is not eternal"
bpm@ec-group.com F. Ballard Washburn
This is the second mention of 'namespace' I have seen. Can we allow
this by default?
Of course, I get:
pgconnection.h:26: warning: namespaces are mostly broken in this version of g++
but it still works. Comments?
> I am using the Sun Workshop C 5.0, noticed that I was getting the
> following errors:
> "pgconnection.h", line 65: Error: string is not defined.
> "pgconnection.cc", line 134: Error: string is not defined.
> "pgconnection.cc", line 139: Error: Cannot return char* from a function
> that should return int.
> 3 Error(s) detected.
>
> Futher looking noticed that the standard namespace was not being used
> for the "string" typedef, so the following patch fixed that for me.
> This is for the 6.5 tar release & the 6/24 CVS checkout.
>
> vlad: diff -w3c interfaces/libpq++/pgconnection.h.orig
> interfaces/libpq++/pgconnection.h
> *** interfaces/libpq++/pgconnection.h.orig Thu Jun 24 10:49:54 1999
>
> --- interfaces/libpq++/pgconnection.h Thu Jun 24 10:48:31 1999
> ***************
> *** 23,28 ****
> --- 23,34 ----
> #include <stdio.h>
> #include <string>
>
> + #ifdef __sun__
> + #ifndef __GNUC__
> + using namespace std;
> + #endif
> + #endif
> +
> extern "C" {
> #include "libpq-fe.h"
> }
>
>
> --
> Brian Millett
> Enterprise Consulting Group "Heaven can not exist,
> (314) 205-9030 If the family is not eternal"
> bpm@ec-group.com F. Ballard Washburn
>
>
>
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
On 08-Jul-99 Bruce Momjian wrote:
>
> This is the second mention of 'namespace' I have seen. Can we allow
> this by default?
>
> Of course, I get:
>
> pgconnection.h:26: warning: namespaces are mostly broken in this version of g++
>
> but it still works. Comments?
Um.. No? Are you also using SWC 5.0? And if it's g++, do we have a version
besides Sun's? Sorry, I'm not familiar with Sun stuff.
Vince.
>
>> I am using the Sun Workshop C 5.0, noticed that I was getting the
>> following errors:
>> "pgconnection.h", line 65: Error: string is not defined.
>> "pgconnection.cc", line 134: Error: string is not defined.
>> "pgconnection.cc", line 139: Error: Cannot return char* from a function
>> that should return int.
>> 3 Error(s) detected.
>>
>> Futher looking noticed that the standard namespace was not being used
>> for the "string" typedef, so the following patch fixed that for me.
>> This is for the 6.5 tar release & the 6/24 CVS checkout.
>>
>> vlad: diff -w3c interfaces/libpq++/pgconnection.h.orig
>> interfaces/libpq++/pgconnection.h
>> *** interfaces/libpq++/pgconnection.h.orig Thu Jun 24 10:49:54 1999
>>
>> --- interfaces/libpq++/pgconnection.h Thu Jun 24 10:48:31 1999
>> ***************
>> *** 23,28 ****
>> --- 23,34 ----
>> #include <stdio.h>
>> #include <string>
>>
>> + #ifdef __sun__
>> + #ifndef __GNUC__
>> + using namespace std;
>> + #endif
>> + #endif
>> +
>> extern "C" {
>> #include "libpq-fe.h"
>> }
>>
>>
>> --
>> Brian Millett
>> Enterprise Consulting Group "Heaven can not exist,
>> (314) 205-9030 If the family is not eternal"
>> bpm@ec-group.com F. Ballard Washburn
>>
>>
>>
>>
>>
>
>
> --
> Bruce Momjian | http://www.op.net/~candle
> maillist@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
> > On 08-Jul-99 Bruce Momjian wrote: > > > > This is the second mention of 'namespace' I have seen. Can we allow > > this by default? > > > > Of course, I get: > > > > pgconnection.h:26: warning: namespaces are mostly broken in this version of g++ > > > > but it still works. Comments? > > Um.. No? Are you also using SWC 5.0? And if it's g++, do we have a version > besides Sun's? Sorry, I'm not familiar with Sun stuff. > > Vince. I am using g++ in gcc 2.7.1. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > > > On 08-Jul-99 Bruce Momjian wrote: > > > > > > This is the second mention of 'namespace' I have seen. Can we allow > > > this by default? > > > > > > Of course, I get: > > > > > > pgconnection.h:26: warning: namespaces are mostly broken in this version of g++ > > > > > > but it still works. Comments? > > > > Um.. No? Are you also using SWC 5.0? And if it's g++, do we have a version > > besides Sun's? Sorry, I'm not familiar with Sun stuff. > > > > Vince. > > I am using g++ in gcc 2.7.1. Remember way back when when I had a #include <something> and it caused problems for some people who really needed #include <something.h> Now I think (but am certainly not sure!) that the difference between the two was meant to be that in the first instance, the standard namespace is used. I can't really follow what's happening as % cvs status pgconnection.cc Fatal error, aborting. : no such user We just changed the first to the second as in g++ all that <something> does is to include <something.h>, but it may not be true for other compilers. Hope someone with a reference book near them can check this! Cheers, Patrick
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>>
>> + #ifdef __sun__
>> + #ifndef __GNUC__
>> + using namespace std;
>> + #endif
>> + #endif
The above is really, really ugly, not to say broken, because neither
being on a Sun nor using gcc have anything to do with whether your
compiler handles namespaces. The problem we are looking at here is that
the C++ standard is a moving target, and some people have compilers that
are newer than others.
I think the proper solution is to add a configure-time test to see
whether a namespace declaration is needed. We could use configure to
see whether we need ".h" on the end of C++ include file references, too.
(That's another thing that's going to be site-dependent for a while to
come.)
regards, tom lane
On Thu, 8 Jul 1999, Tom Lane wrote:
> I think the proper solution is to add a configure-time test to see
> whether a namespace declaration is needed. We could use configure to
> see whether we need ".h" on the end of C++ include file references, too.
> (That's another thing that's going to be site-dependent for a while to
> come.)
Hmmm. I'm running 2.7.2.1 here and in the case of <string> I have a
file called: /usr/include/g++/string <-- note there's no .h on the end.
Am I being dense here and missing something or does this differ from what
other folks have? There's also a number of other files without the .h
extension in that directory. string includes std/string.h.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> On Thu, 8 Jul 1999, Tom Lane wrote:
>> I think the proper solution is to add a configure-time test to see
>> whether a namespace declaration is needed. We could use configure to
>> see whether we need ".h" on the end of C++ include file references, too.
>> (That's another thing that's going to be site-dependent for a while to
>> come.)
> Hmmm. I'm running 2.7.2.1 here and in the case of <string> I have a
> file called: /usr/include/g++/string <-- note there's no .h on the end.
> Am I being dense here and missing something or does this differ from what
> other folks have?
Same as what I have, but I'm using gcc 2.7.2.2 so that's not real
surprising. I was under the impression that naming conventions for
C++ library include files have changed at least once in the development
of the C++ standards --- but I may be mistaken.
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> > >> + #ifdef __sun__ > >> + #ifndef __GNUC__ > >> + using namespace std; > >> + #endif > >> + #endif Yes, never applied. > The above is really, really ugly, not to say broken, because neither > being on a Sun nor using gcc have anything to do with whether your > compiler handles namespaces. The problem we are looking at here is that > the C++ standard is a moving target, and some people have compilers that > are newer than others. > > I think the proper solution is to add a configure-time test to see > whether a namespace declaration is needed. We could use configure to > see whether we need ".h" on the end of C++ include file references, too. > (That's another thing that's going to be site-dependent for a while to > come.) I smell TODO list: * Add configure test to check for C++ need for *.h and namespaces Added. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> On Thu, 8 Jul 1999, Tom Lane wrote: > > > I think the proper solution is to add a configure-time test to see > > whether a namespace declaration is needed. We could use configure to > > see whether we need ".h" on the end of C++ include file references, too. > > (That's another thing that's going to be site-dependent for a while to > > come.) > > Hmmm. I'm running 2.7.2.1 here and in the case of <string> I have a > file called: /usr/include/g++/string <-- note there's no .h on the end. > Am I being dense here and missing something or does this differ from what > other folks have? There's also a number of other files without the .h > extension in that directory. string includes std/string.h. > We remove .h, and someone complains, we add .h, and someone complains, but fewer people. Configure is the answer. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> > >> + #ifdef __sun__ > >> + #ifndef __GNUC__ > >> + using namespace std; > >> + #endif > >> + #endif Yes, never applied. > The above is really, really ugly, not to say broken, because neither > being on a Sun nor using gcc have anything to do with whether your > compiler handles namespaces. The problem we are looking at here is that > the C++ standard is a moving target, and some people have compilers that > are newer than others. > > I think the proper solution is to add a configure-time test to see > whether a namespace declaration is needed. We could use configure to > see whether we need ".h" on the end of C++ include file references, too. > (That's another thing that's going to be site-dependent for a while to > come.) I smell TODO list: * Add configure test to check for C++ need for *.h and namespaces Added. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thu, 8 Jul 1999, Bruce Momjian wrote:
>
> > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > >>
> > >> + #ifdef __sun__
> > >> + #ifndef __GNUC__
Looks like someone's mailer reinjected this one.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
> On Thu, 8 Jul 1999, Bruce Momjian wrote: > > > > > > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > > >> > > > >> + #ifdef __sun__ > > > >> + #ifndef __GNUC__ > > Looks like someone's mailer reinjected this one. > We removed the __sun__ line because it was considered strange. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 26 Jul 1999, Bruce Momjian wrote:
> > On Thu, 8 Jul 1999, Bruce Momjian wrote:
> >
> > >
> > > > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > > > >>
> > > > >> + #ifdef __sun__
> > > > >> + #ifndef __GNUC__
> >
> > Looks like someone's mailer reinjected this one.
> >
>
> We removed the __sun__ line because it was considered strange.
>
>
Look at the date of the message. Someone from a2000.nl is reinjecting
messages to the list. That's all my note was about. I've seen a few
of 'em so far this mourning.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> Looks like someone's mailer reinjected this one.
Yes, along with five others that were also about two weeks old.
I recall having noticed several other such incidents in the recent
past, all bearing headers that indicate the retransmitted messages
originally went from the mail list to one <Z.Nijmeyers@cable.a2000.nl>.
Start of reinjection of this one (note date):
Received: from hardy-1.a2000.nl ([127.0.0.1]) by hardy-1.a2000.nl (Netscape Messaging Server 3.6) with SMTP id
AAA5185; Mon, 26 Jul 1999 13:34:05 +0200
Immediately prior Received: lines:
Received: from smtp1.a2000.nl ([192.168.17.19]) by hardy-1.a2000.nl (Netscape Messaging Server 3.6) with ESMTP
idAAT19D0 for <Z.Nijmeyers@cable.a2000.nl>; Fri, 9 Jul 1999 06:48:41 +0200
Received: from hub.org ([209.167.229.1])by smtp1.a2000.nl with esmtp (Exim 2.02 #4)id 112SYe-0002lN-00for
Z.Nijmeyers@cable.a2000.nl;Fri, 9 Jul 1999 06:46:44 +0200
Received: from hub.org (hub.org [209.167.229.1])by hub.org (8.9.3/8.9.3) with ESMTP id AAA39425;Fri, 9 Jul 1999
00:40:25-0400 (EDT)(envelope-from owner-pgsql-hackers@hub.org)
This morning I sent a polite note to postmaster@cable.a2000.nl, warning
them that they've got a problem with mail looping. It promptly bounced
back with
postmaster@cable.a2000.nl: SMTP error from remote mailer after RCPT TO: <postmaster@cable.a2000.nl>: host
hardy-1.a2000.nl[192.168.17.13]: 550 Invalid recipient <postmaster@cable.a2000.nl>
(Sending to postmaster@a2000.nl instead probably won't help, since it
MX's to the same machines.)
I conclude that a2000.nl is run by a bunch of idiots who can't read
RFCs, let alone operate a mail server competently. I expect that
we will continue to get blessed with regurgitated messages until Marc
pulls any a2000.nl addresses from the mailing lists :-(
regards, tom lane
Re: Mail loop at a2000.nl (was Re: [HACKERS] PATCH for pgconnection.h)
From
wieck@debis.com (Jan Wieck)
Date:
Tom Lane wrote:
> Received: from hardy-1.a2000.nl ([127.0.0.1]) by hardy-1.a2000.nl
> (Netscape Messaging Server 3.6) with SMTP id AAA5185;
> Mon, 26 Jul 1999 13:34:05 +0200
>
> Immediately prior Received: lines:
>
> Received: from smtp1.a2000.nl ([192.168.17.19]) by hardy-1.a2000.nl
> (Netscape Messaging Server 3.6) with ESMTP id AAT19D0
> for <Z.Nijmeyers@cable.a2000.nl>; Fri, 9 Jul 1999 06:48:41 +0200
And look at the dates!
>
> This morning I sent a polite note to postmaster@cable.a2000.nl, warning
> them that they've got a problem with mail looping. It promptly bounced
> back with
>
> postmaster@cable.a2000.nl:
> SMTP error from remote mailer after RCPT TO:
> <postmaster@cable.a2000.nl>:
> host hardy-1.a2000.nl [192.168.17.13]:
> 550 Invalid recipient <postmaster@cable.a2000.nl>
I've also tried to send to postmaster@hardy-1.a2000.nl.
Result: unknown host :-)
But the CC to Z.Nijmeyers@cable.a2000.nl didn't bounce. Maybe
he'll receive it and can forward it in HARDCOPY to his
pEstmaster.
>
> (Sending to postmaster@a2000.nl instead probably won't help, since it
> MX's to the same machines.)
>
> I conclude that a2000.nl is run by a bunch of idiots who can't read
> RFCs, let alone operate a mail server competently. I expect that
> we will continue to get blessed with regurgitated messages until Marc
> pulls any a2000.nl addresses from the mailing lists :-(
NC
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
going...going...gone...
On Mon, 26 Jul 1999, Tom Lane wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
> > Looks like someone's mailer reinjected this one.
>
> Yes, along with five others that were also about two weeks old.
> I recall having noticed several other such incidents in the recent
> past, all bearing headers that indicate the retransmitted messages
> originally went from the mail list to one <Z.Nijmeyers@cable.a2000.nl>.
>
> Start of reinjection of this one (note date):
>
> Received: from hardy-1.a2000.nl ([127.0.0.1]) by hardy-1.a2000.nl
> (Netscape Messaging Server 3.6) with SMTP id AAA5185;
> Mon, 26 Jul 1999 13:34:05 +0200
>
> Immediately prior Received: lines:
>
> Received: from smtp1.a2000.nl ([192.168.17.19]) by hardy-1.a2000.nl
> (Netscape Messaging Server 3.6) with ESMTP id AAT19D0
> for <Z.Nijmeyers@cable.a2000.nl>; Fri, 9 Jul 1999 06:48:41 +0200
> Received: from hub.org ([209.167.229.1])
> by smtp1.a2000.nl with esmtp (Exim 2.02 #4)
> id 112SYe-0002lN-00
> for Z.Nijmeyers@cable.a2000.nl; Fri, 9 Jul 1999 06:46:44 +0200
> Received: from hub.org (hub.org [209.167.229.1])
> by hub.org (8.9.3/8.9.3) with ESMTP id AAA39425;
> Fri, 9 Jul 1999 00:40:25 -0400 (EDT)
> (envelope-from owner-pgsql-hackers@hub.org)
>
> This morning I sent a polite note to postmaster@cable.a2000.nl, warning
> them that they've got a problem with mail looping. It promptly bounced
> back with
>
> postmaster@cable.a2000.nl:
> SMTP error from remote mailer after RCPT TO:
> <postmaster@cable.a2000.nl>:
> host hardy-1.a2000.nl [192.168.17.13]:
> 550 Invalid recipient <postmaster@cable.a2000.nl>
>
> (Sending to postmaster@a2000.nl instead probably won't help, since it
> MX's to the same machines.)
>
> I conclude that a2000.nl is run by a bunch of idiots who can't read
> RFCs, let alone operate a mail server competently. I expect that
> we will continue to get blessed with regurgitated messages until Marc
> pulls any a2000.nl addresses from the mailing lists :-(
>
> regards, tom lane
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I conclude that a2000.nl is run by a bunch of idiots who can't read > RFCs, let alone operate a mail server competently. I expect that > we will continue to get blessed with regurgitated messages until Marc > pulls any a2000.nl addresses from the mailing lists :-( Could be that they're idiots, if so I hope they can find some competent people to help them out there. They're the TV cable operators for Amsterdam and surroundings and have probably about half a million houses connected to their network. Since about a year and a half (I guess) they're into internet over cable modems, and actually the bandwidth they deliver is pretty impressive (especially if you're used to 28k8 modems ;) Maarten -- Maarten Boekhold, boekhold@tibco.com TIBCO Finance Technology Inc. The Atrium Strawinskylaan 3051 1077 ZX Amsterdam, The Netherlands tel: +31 20 3012158, fax: +31 20 3012358 http://www.tibco.com
At 17:03 26-7-99 +0200, Jan Wieck wrote: > And look at the dates! >> This morning I sent a polite note to postmaster@cable.a2000.nl, warning >> them that they've got a problem with mail looping. It promptly bounced >> back with > But the CC to Z.Nijmeyers@cable.a2000.nl didn't bounce. Maybe > he'll receive it and can forward it in HARDCOPY to his > pEstmaster. I'm really sorry that my ISP is doing wonderful :-) things to it's mail-servers >> I conclude that a2000.nl is run by a bunch of idiots who can't read >> RFCs, let alone operate a mail server competently. I expect that they are a bunch of idiots and complaining doesn't help a bit, in the past couple of weeks everyone in amsterdam who has cable internet, has had extreme trouble with email. >> we will continue to get blessed with regurgitated messages until Marc >> pulls any a2000.nl addresses from the mailing lists :-( If the problem persists with a2000 messages looping back please let me know and I will unsubscribe from the list and resubscribe using another email address