Thread
Commits
-
ecpg: Catch zero-length Unicode identifiers correctly
- a18b6d2dc288 15.0 landed
-
small bug in ecpg unicode identifier error handling
Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-01-10T13:14:37Z
I think this patch is necessary: diff --git a/src/interfaces/ecpg/preproc/pgc.l b/src/interfaces/ecpg/preproc/pgc.l index 07fee80a9c..3529b2ea86 100644 --- a/src/interfaces/ecpg/preproc/pgc.l +++ b/src/interfaces/ecpg/preproc/pgc.l @@ -753,7 +753,7 @@ cppline {space}*#([^i][A-Za-z]*|{if}|{ifdef}|{ifndef}|{import})((\/\*[^*/]*\*+ } <xui>{dquote} { BEGIN(state_before_str_start); - if (literallen == 2) /* "U&" */ + if (literallen == 0) mmerror(PARSE_ERROR, ET_ERROR, "zero-length delimited identifier"); /* The backend will truncate the identifier here. We do not as it does not change the result. */ base_yylval.str = psprintf("U&\"%s\"", literalbuf); The old code doesn't make sense. The literallen is the length of the data in literalbuf, which clearly doesn't include the "U&" as the comment suggests. A test case is to preprocess a file like this (ecpg test.pgc): exec sql select u&" which currently does *not* give the above error, but it should. -
Re: small bug in ecpg unicode identifier error handling
Tom Lane <tgl@sss.pgh.pa.us> — 2022-01-10T15:05:22Z
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > I think this patch is necessary: > - if (literallen == 2) /* "U&" */ > + if (literallen == 0) Seems sensible, and matches the corresponding code in scan.l. +1. regards, tom lane
-
Re: small bug in ecpg unicode identifier error handling
Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-01-12T10:00:21Z
On 10.01.22 14:14, Peter Eisentraut wrote: > I think this patch is necessary: > > diff --git a/src/interfaces/ecpg/preproc/pgc.l > b/src/interfaces/ecpg/preproc/pgc.l > index 07fee80a9c..3529b2ea86 100644 > --- a/src/interfaces/ecpg/preproc/pgc.l > +++ b/src/interfaces/ecpg/preproc/pgc.l > @@ -753,7 +753,7 @@ cppline > {space}*#([^i][A-Za-z]*|{if}|{ifdef}|{ifndef}|{import})((\/\*[^*/]*\*+ > } > <xui>{dquote} { > BEGIN(state_before_str_start); > - if (literallen == 2) /* "U&" */ > + if (literallen == 0) > mmerror(PARSE_ERROR, ET_ERROR, "zero-length > delimited identifier"); > /* The backend will truncate the identifier here. > We do not as it does not change the result. */ > base_yylval.str = psprintf("U&\"%s\"", literalbuf); > > The old code doesn't make sense. The literallen is the length of the > data in literalbuf, which clearly doesn't include the "U&" as the > comment suggests. > > A test case is to preprocess a file like this (ecpg test.pgc): > > exec sql select u&" > > which currently does *not* give the above error, but it should. Committed. For the record, the correct test case was actually exec sql select u&"";