Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fklHh-0004n8-Q1 for pgsql-interfaces@arkaria.postgresql.org; Wed, 01 Aug 2018 07:11:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fklHf-0005Q8-Rx for pgsql-interfaces@arkaria.postgresql.org; Wed, 01 Aug 2018 07:10:59 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fklHf-0005Q1-Ir for pgsql-interfaces@lists.postgresql.org; Wed, 01 Aug 2018 07:10:59 +0000 Received: from [49.255.133.214] (helo=mx1.constrainttec.com) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fklHb-0005w9-FX for pgsql-interfaces@postgresql.org; Wed, 01 Aug 2018 07:10:57 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.constrainttec.com (Postfix) with ESMTP id 8ACDA15DB786 for ; Wed, 1 Aug 2018 07:10:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at maat.constrainttec.com Received: from mx1.constrainttec.com ([127.0.0.1]) by localhost (maat.contecint.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WmR-UKA783X; Wed, 1 Aug 2018 17:10:50 +1000 (AEST) Received: from starscream (dhcp-136.contecint.com.au [10.224.200.136]) by mx1.constrainttec.com (Postfix) with ESMTP id A83AA15D96BA for ; Wed, 1 Aug 2018 17:10:50 +1000 (AEST) From: "Sam Liapis" To: Subject: Does ecpg understand forward declarations? Date: Wed, 1 Aug 2018 17:10:51 +1000 Message-ID: <019201d42966$c8071f60$58155e20$@constrainttec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01D429BA.99B5A060" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-au Thread-Index: AdQpZn+njmM7gRioRjeMhmfhvndpCg== X-Host-Lookup-Failed: Reverse DNS lookup failed for 49.255.133.214 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_0193_01D429BA.99B5A060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [Retransmitting from MS mail client in the hope message is well formatted] I'm a newbie to postgresql and ecpg in particular. My brief is to 'convert' Oracle pro*C files ready for ecpg preprocessing. I've so far struck what appears to be ecpg limitation such as multi-dim arrays, function pointers and void type. But the one that's biting hard right now is ecpg seems to be unaware of or ignores forward declarations. Take the classic scenario of mutually dependent structs A & B shown below. ECPG keeps bailing with "ERROR: unrecognized data type name struct B" (at line 100) If I remove the forward declaration its the same error for line 110 (struct B* ptr;) 100 struct B; 101 102 struct A { ... 110 struct B* ptr; 111 }; 112 113 struct B { ... 120 struct A* ptr; 121 }; Can someone confirm this indeed is a shortcoming of ecpg and suggest any way around it? Thanks, Sam ------=_NextPart_000_0193_01D429BA.99B5A060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Retransmitting from MS mail client in the hope = message is well formatted]

 

I'm a newbie = to postgresql and ecpg in particular.

 

My brief is = to 'convert' Oracle pro*C files ready for ecpg = preprocessing.

 

I've so far = struck what appears to be ecpg limitation such as multi-dim arrays, = function pointers and void type.

But = the one that's biting hard right now is ecpg seems to be unaware of or = ignores forward declarations.

Take = the classic scenario of mutually dependent structs A & B shown = below.

 

ECPG keeps bailing with "ERROR: unrecognized data = type name struct B" (at line 100)

If I remove the forward declaration its the same error = for line 110 (struct B* ptr;)

 

100 =  struct B;

101

102 struct A {

   =       ...

110      struct B* = ptr;

111  };

112

113 =  struct B {

     =     ...

120      struct A* = ptr;

121 };

 

Can someone = confirm this indeed is a shortcoming of ecpg and suggest any way around = it?

 

Thanks,

Sam

------=_NextPart_000_0193_01D429BA.99B5A060--