From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: ecpg: issue related to preprocessor directives |
Date: | 2020-08-03 10:30:06 |
Message-ID: | CAE9k0Pm1nzxJsmHM77ZmyCG==89mKyYqofz93WkqBm7LgtiiGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
On Sat, Aug 1, 2020 at 5:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> writes:
> > When the following ecpg program having preprocessor directives is compiled,
> > the output produced is not correct.
> > ...
> > As seen from above output, both exec sql ifdef and exec sql else block got
> > compiled which is wrong. If the above output is further compiled using gcc
> > compiler, the compilation would fail.
>
> Looking at pgc.l, it seems that 'elif' is treated as though it were
> 'endif' followed by 'ifdef', which of course completely loses the
> expected property that a previous successful branch would keep the
> elif branch from being expanded.
Yeah, that's right. The point is, while processing the elif branch, we
remove an entry for the previous branch (ifdef, ifndef) from the stack
and push a new entry for the current elif branch. So, if the elif
branch is evaluated to false, the else branch gets automatically
evaluated to true. And as a result of that both ifdef and else branch
gets evaluated to true thereby compiling both (ifdef/ifndef, else)
blocks.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2020-08-03 10:39:10 | Re: ecpg: issue related to preprocessor directives |
Previous Message | Tom Lane | 2020-08-01 14:35:31 | Re: ecpg: issue related to preprocessor directives |