Re: BUG #13676: C typedef code generated by ecpg with wrong syntax - Mailing list pgsql-bugs

From John McKown
Subject Re: BUG #13676: C typedef code generated by ecpg with wrong syntax
Date
Msg-id CAAJSdjg+9aHzvSsiOOTqBc=8WjiK=G5b5Fza9oRt=QO4AAcy9w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #13676: C typedef code generated by ecpg with wrong syntax  (Michael Meskes <meskes@postgresql.org>)
Responses Re: BUG #13676: C typedef code generated by ecpg with wrong syntax  (Gláucio Barros Barcelos <glauciobb@hotmail.com>)
List pgsql-bugs
I did a "git pull" from the PostrgeSQL repository. then did a "make ecpg"
in the src/interfaces/ecpg directory. I then used the new ecpg on the
example code, followed by a gcc compile. The compile went fine. I made a
slight change to the code, just because to be:

#include <stdio.h>
EXEC SQL TYPE t_char_10  IS char[10];
EXEC SQL TYPE t_char_10d  IS struct { char data[10];};
EXEC SQL TYPE char_ptr IS char reference;
int main()
{
    t_char_10 string10;
    int len=3Dsizeof string10;
    printf("size is: %d\n",len);
    int status =3D 0;
    return status;
}

And then:

ecpg -c test-ecpg.pgc && gcc test-ecpg.c && ./a.out

which printed:

size is 10

Looks good to me on Linux, Fedora 22 x86_64.

On Fri, Oct 16, 2015 at 10:33 AM, Michael Meskes <meskes@postgresql.org>
wrote:

> > I trying to migrate my application developed using Pro*c to ECPG. But,
> when
> > I run the code below with "ecpg -c" command to generate c code, the
> syntax
> > for typedef generated appears to be wrong. Below is an sample code and
> the
> > steps to generate error return by C compiler due the wrong syntax for
> > typedef.
>
> Thanks for spotting and reporting. The order of the arguments seems to be
> broken.
>
> Please try this to fix:
> diff --git a/src/interfaces/ecpg/preproc/ecpg.trailer
> b/src/interfaces/ecpg/preproc/ecpg.trailer
> index 8cc3844..16359a3 100644
> --- a/src/interfaces/ecpg/preproc/ecpg.trailer
> +++ b/src/interfaces/ecpg/preproc/ecpg.trailer
> @@ -1311,7 +1311,7 @@ ECPGTypedef: TYPE_P
>                         if (auto_create_c =3D=3D false)
>                                 $$ =3D cat_str(7, mm_strdup("/* exec sql
> type"),
> mm_strdup($3), mm_strdup("is"), mm_strdup($5.type_str), mm_strdup($6.str)=
,
> $7,
> mm_strdup("*/"));
>                         else
> -                               $$ =3D cat_str(6, mm_strdup("typedef "),
> mm_strdup($5.type_str), *$7?mm_strdup("*"):mm_strdup(""),
> mm_strdup($6.str),
> mm_strdup($3), mm_strdup(";"));
> +                               $$ =3D cat_str(6, mm_strdup("typedef "),
> mm_strdup($5.type_str), *$7?mm_strdup("*"):mm_strdup(""), mm_strdup($3),
> mm_strdup($6.str), mm_strdup(";"));
>                 }
>                 ;
>
> Already committed to HEAD. Will do backports later.
>
> Thanks again.
>
> Michael
> --
> Michael Meskes
> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> Meskes at (Debian|Postgresql) dot Org
> Jabber: michael.meskes at gmail dot com
> VfL Borussia! For=C3=A7a Bar=C3=A7a! Go SF 49ers! Use Debian GNU/Linux, P=
ostgreSQL
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>



--=20

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones =3D 1 Megaphone

Maranatha! <><
John McKown

pgsql-bugs by date:

Previous
From: cdaringe@gmail.com
Date:
Subject: BUG #13684: pg_restore does not restore indexes when --jobs=X passed
Next
From: l@lrowe.co.uk
Date:
Subject: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby