Thread: 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 }
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
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
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
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