Обсуждение: BUG #13676: C typedef code generated by ecpg with wrong syntax

The following bug has been logged on the website:

Bug reference:      13676
Logged by:          Gláucio Barros Barcelos
Email address:      glauciobb@hotmail.com
PostgreSQL version: 9.4.5
Operating system:   Oracle Linux Server release 6.7
Description:

Dear,

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.

Step 1: Create a file with pgc extension with the code below:

#include <stdio.h>
EXEC SQL TYPE t_char_10  IS char[10];
int main()
{
    int status = 0;
    return status;
}

Step 2: pre compile the file with command: ecpg -c file.pgc. This command
will generate the c code below. Note that the  syntax for typedef is wrong.


/* Processed by ecpg (4.10.0) */
/* These include files are added by the preprocessor */
#include <ecpglib.h>
#include <ecpgerrno.h>
#include <sqlca.h>
/* End of automatic include section */

#line 1 "example.pgc"
#include <stdio.h>

typedef  char [ 10 ] t_char_10 ;
#line 3 "example.pgc"

int main()
{
    int status = 0;
    return status;
}

Step 3: Try to compile the c code with command "cc -I/usr/pgsql-9.4/include
-c file.c".

file.pgc:3 error: expected indentifier or '(' before '[' token

best regards,
Gláucio

This is just me, but I'm wondering if the examples on page:
http://www.postgresql.org/docs/9.4/static/ecpg-sql-type.html are
misleading. The text on that page says "TYPE type_name IS ctype" and
defines ctype as "a C type specification". The example on that page, which
is similar to yours is:

EXEC SQL TYPE string IS char[11];

But I am fairly user that "char[11]" is _not_ a "C type specification". An
"array" is not a C type. A "char" is. As are things like: int, long int,
float, double, etc. I.e. you say "char data[10];" and not "char[10] data".
C doesn't have a "string" data type.

So I'm wondering if the ecpg processor is doing things correctly but the
examples are bad.

I not saying, I'm asking.

On Tue, Oct 13, 2015 at 2:27 PM, <glauciobb@hotmail.com> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      13676
> Logged by:          Gl=C3=A1ucio Barros Barcelos
> Email address:      glauciobb@hotmail.com
> PostgreSQL version: 9.4.5
> Operating system:   Oracle Linux Server release 6.7
> Description:
>
> Dear,
>
> I trying to migrate my application developed using Pro*c to ECPG. But, wh=
en
> I run the code below with "ecpg -c" command to generate c code, the synta=
x
> for typedef generated appears to be wrong. Below is an sample code and th=
e
> steps to generate error return by C compiler due the wrong syntax for
> typedef.
>
> Step 1: Create a file with pgc extension with the code below:
>
> #include <stdio.h>
> EXEC SQL TYPE t_char_10  IS char[10];
> int main()
> {
>         int status =3D 0;
>         return status;
> }
>
> Step 2: pre compile the file with command: ecpg -c file.pgc. This command
> will generate the c code below. Note that the  syntax for typedef is wron=
g.
>
>
> /* Processed by ecpg (4.10.0) */
> /* These include files are added by the preprocessor */
> #include <ecpglib.h>
> #include <ecpgerrno.h>
> #include <sqlca.h>
> /* End of automatic include section */
>
> #line 1 "example.pgc"
> #include <stdio.h>
>
> typedef  char [ 10 ] t_char_10 ;
> #line 3 "example.pgc"
>
> int main()
> {
>         int status =3D 0;
>         return status;
> }
>
> Step 3: Try to compile the c code with command "cc -I/usr/pgsql-9.4/inclu=
de
> -c file.c".
>
> file.pgc:3 error: expected indentifier or '(' before '[' token
>
> best regards,
> Gl=C3=A1ucio
>
>
>
> --
> 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

> 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 s=
yntax
> for typedef generated appears to be wrong. Below is an sample code an=
d 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=20
broken.

Please try this to fix:
diff --git a/src/interfaces/ecpg/preproc/ecpg.trailer=20
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 sq=
l type"),=20
mm_strdup($3), mm_strdup("is"), mm_strdup($5.type_str), mm_strdup($6.st=
r), $7,=20
mm_strdup("*/"));
                        else
-                               $$ =3D cat_str(6, mm_strdup("typedef ")=
,=20
mm_strdup($5.type_str), *$7?mm_strdup("*"):mm_strdup(""), mm_strdup($6.=
str),=20
mm_strdup($3), mm_strdup(";"));
+                               $$ =3D cat_str(6, mm_strdup("typedef ")=
,=20
mm_strdup($5.type_str), *$7?mm_strdup("*"):mm_strdup(""), mm_strdup($3)=
,=20
mm_strdup($6.str), mm_strdup(";"));
                }
                ;

Already committed to HEAD. Will do backports later.

Thanks again.

Michael
--=20
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=E7a Bar=E7a! Go SF 49ers! Use Debian GNU/Linux, Postg=
reSQL

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