BUG #13688: lack of return value in r_mark_regions()
The following bug has been logged on the website:
Bug reference: 13688
Logged by: Zhang Yan
Email address: rucsoftsec@163.com
PostgreSQL version: 9.4.5
Operating system: Linux Mint 15
Description:
For each execuation result of function r_mark_regions(), it always return 1.
the related code snippets in r_mark_regions() are as following.
354 static int r_mark_regions(struct SN_env * z) {
355 z->I[0] = z->l;
356 z->I[1] = z->l;
357 { int c1 = z->c; /* do, line 63 */
358 { /* gopast */ /* grouping v, line 64 */
359 int ret = out_grouping(z, g_v, 192, 220, 1);
360 if (ret < 0) goto lab0;
361 z->c += ret;
362 }
363 z->I[0] = z->c; /* setmark pV, line 64 */
364 { /* gopast */ /* non v, line 64 */
365 int ret = in_grouping(z, g_v, 192, 220, 1);
366 if (ret < 0) goto lab0;
367 z->c += ret;
368 }
369 { /* gopast */ /* grouping v, line 65 */
370 int ret = out_grouping(z, g_v, 192, 220, 1);
371 if (ret < 0) goto lab0;
372 z->c += ret;
373 }
374 { /* gopast */ /* non v, line 65 */
375 int ret = in_grouping(z, g_v, 192, 220, 1);
376 if (ret < 0) goto lab0;
377 z->c += ret;
378 }
379 z->I[1] = z->c; /* setmark p2, line 65 */
380 lab0:
381 z->c = c1;
382 }
383 return 1;
384 }
However, in its caller function, the return value of function
r_mark_regions() should have two possibilities at least. So, there lack of
return value in r_mark_regions().
The related code snippets in russian_KOI8_R_stem() are as following.
604 extern int russian_KOI8_R_stem(struct SN_env * z) {
605 { int c1 = z->c; /* do, line 203 */
606 { int ret = r_mark_regions(z);
607 if (ret == 0) goto lab0; /* call mark_regions, line 203 */
608 if (ret < 0) return ret;
609 }
610 lab0:
611 z->c = c1;
612 }
......
693 z->c = z->lb;
694 return 1;
695 }
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rucsoftsec@163.com wrote:
For each execuation result of function r_mark_regions(), it always return 1.
the related code snippets in r_mark_regions() are as following.
[...]
However, in its caller function, the return value of function
r_mark_regions() should have two possibilities at least. So, there lack of
return value in r_mark_regions().
We're only consumers of the snowball code; we do not maintain those
files. Have you checked the upstream code?
I notice we haven't updated those files since they were first introduced
in 2007. That can't be right ...
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
I notice we haven't updated those files since they were first introduced
in 2007. That can't be right ...
Unfortunately, snowball development is nearly dead. (We seem to have a
bad habit of outliving projects we depend on ...) I think there were
some minor bug fixes since we copied the code, but no new formal release,
which is why I hadn't gotten motivated to update. Dunno if this
particular issue is fixed upstream.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
I notice we haven't updated those files since they were first introduced
in 2007. That can't be right ...Unfortunately, snowball development is nearly dead. (We seem to have a
bad habit of outliving projects we depend on ...) I think there were
some minor bug fixes since we copied the code, but no new formal release,
which is why I hadn't gotten motivated to update. Dunno if this
particular issue is fixed upstream.
Apparently, there's a month-old effort to revive it at
http://snowballstem.org/ It's probably too new to be depend on it yet,
but there are plenty of commits to the source repo.
However, the maintainer posted to alert that the license is actually
3-clause BSD: http://article.gmane.org/gmane.comp.search.snowball/1558
which is OpenSSL-level licensing nightmare all over again ...
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
Unfortunately, snowball development is nearly dead.
Apparently, there's a month-old effort to revive it at
http://snowballstem.org/ It's probably too new to be depend on it yet,
but there are plenty of commits to the source repo.
However, the maintainer posted to alert that the license is actually
3-clause BSD: http://article.gmane.org/gmane.comp.search.snowball/1558
which is OpenSSL-level licensing nightmare all over again ...
Ugh. It looks to me like Olly has no idea that the third clause is a
serious problem for some downstream projects. And although I'm subscribed
to snowball-discuss, I never got that message (or I'd have said
something...)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs