* Categories containing "++" make gnatsweb crash @ 2003-01-20 14:34 Dieperink Alwin 2003-04-29 19:47 ` Yngve Svendsen 0 siblings, 1 reply; 5+ messages in thread From: Dieperink Alwin @ 2003-01-20 14:34 UTC (permalink / raw) To: 'help-gnats@gnu.org' Hello, When categories contain a "++" in their name, gnatsweb crashes with the following error: Nested quantifiers in regex; marked by <-- HERE in m/^client-c++ <-- HERE $/ at /home/gnats/cgi-bin/gnatsweb.pl line 1610, <SOCK> line 2173. which points to the line containing grep in this piece of code: sub edit ... if (fieldinfo ($_, 'fieldtype') eq 'enum') { my $default = $fields{$_}; # Check whether field value is a known enumeration value. if (!(grep /^$default$/, @$values)) { push(@$values, 'unknown') if (!grep /^unknown$/, @$values); $default = 'unknown'; } print popup_or_scrolling_menu($_, $values, $default), "</td>\n</tr>\n"; } ... When I replaced the name of the category client-c++ with client-cpp and made all necessary changes in the PR's it works fine. The example file "categories" doesn't warn against this and in there is an example which wouldn't work (g++). There are several solutions: 1) restrict the use of special characters in category names and correct "categories" 2) correct the use of grep in gnatsweb. 3) ... My preference goes actually to the first solution. Regards -- Alwin Environment: Gnatsweb v3.99.4, Gnats v4.0-beta2 _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Categories containing "++" make gnatsweb crash 2003-01-20 14:34 Categories containing "++" make gnatsweb crash Dieperink Alwin @ 2003-04-29 19:47 ` Yngve Svendsen 2003-05-05 17:48 ` Lars Henriksen 0 siblings, 1 reply; 5+ messages in thread From: Yngve Svendsen @ 2003-04-29 19:47 UTC (permalink / raw) To: Dieperink Alwin, 'help-gnats@gnu.org' At 15:28 20.01.2003 +0100, Dieperink Alwin wrote: >Hello, > >When categories contain a "++" in their name, gnatsweb crashes with the >following error: (snip) >There are several solutions: >1) restrict the use of special characters in category names and correct >"categories" >2) correct the use of grep in gnatsweb. >3) ... > >My preference goes actually to the first solution. Thanks for reporting this. I ended up modifying the code to avoid the use of grep -- it wasn't a good idea to use it anyway since it is an unnecessarily expensive operation in this context. And moreover, I do not want to assume anything about allowed characters in GNATS category names. Yngve Svendsen Gnatsweb maintainer _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Categories containing "++" make gnatsweb crash 2003-04-29 19:47 ` Yngve Svendsen @ 2003-05-05 17:48 ` Lars Henriksen 2003-05-06 9:31 ` Yngve Svendsen 2003-05-06 21:13 ` Yngve Svendsen 0 siblings, 2 replies; 5+ messages in thread From: Lars Henriksen @ 2003-05-05 17:48 UTC (permalink / raw) To: Yngve Svendsen; +Cc: 'help-gnats@gnu.org', Dieperink Alwin On Tue, Apr 29, 2003 at 09:39:54PM +0200, Yngve Svendsen wrote: > At 15:28 20.01.2003 +0100, Dieperink Alwin wrote: > >Hello, > > > >When categories contain a "++" in their name, gnatsweb crashes with the > >following error: > > (snip) > > >There are several solutions: > >1) restrict the use of special characters in category names and correct > >"categories" > >2) correct the use of grep in gnatsweb. > >3) ... > > > >My preference goes actually to the first solution. > > Thanks for reporting this. I ended up modifying the code to avoid the use > of grep -- it wasn't a good idea to use it anyway since it is an > unnecessarily expensive operation in this context. And moreover, I do not > want to assume anything about allowed characters in GNATS category names. Here is the code: Index: gnatsweb.pl =================================================================== RCS file: /cvsroot/gnatsweb/gnatsweb/gnatsweb.pl,v retrieving revision 1.120 retrieving revision 1.121 diff -c -r1.120 -r1.121 *** gnatsweb.pl 8 Jan 2003 13:04:17 -0000 1.120 --- gnatsweb.pl 29 Apr 2003 19:25:35 -0000 1.121 [snip] *** 1577,1588 **** if (fieldinfo ($_, 'fieldtype') eq 'enum') { my $default = $fields{$_}; # Check whether field value is a known enumeration value. ! if (!(grep /^$default$/, @$values)) ! { ! push(@$values, 'unknown') if (!grep /^unknown$/, @$values); ! $default = 'unknown'; ! } print popup_or_scrolling_menu($_, $values, $default), "</td>\n</tr>\n"; } --- 1577,1595 ---- if (fieldinfo ($_, 'fieldtype') eq 'enum') { my $default = $fields{$_}; + my $found = 0; # Check whether field value is a known enumeration value. ! foreach(@$values) ! { ! next if ($_ ne $default); ! $found = 1; ! last; ! } ! unless ($found) ! { ! push(@$values, 'unknown'); ! $default = 'unknown'; ! } print popup_or_scrolling_menu($_, $values, $default), "</td>\n</tr>\n"; } I agree that assumptions about characters should be avoided and that the foreach-construction does this, but please lecture me: is perl-grep particularly expensive?. I have another comment, though. If the field value isn't a known enumeration value, the value 'unknown' is inserted in the enumeration array and made the default value for display. But in my original code the insertion of 'unknown' only happened if it wasn't already there (the second grep operation above). The reason is that 'unknown' may be a perfectly valid enumeration value (and if it is already there, we don't want to insert it a second time). E.g. I have the following entry in the responsible file: unknown:The name is not in the responsible file - use "view" to see it.:gnats-admin If you edit a PR with an unknown responsible, the descriptive text is then diplayed as a guide to the user. Here is a suggestion for a modified foreach-loop: my $found = 0; my $nopush = 0; # Check whether field value is a known enumeration value. foreach(@$values) { $found = 1 if $_ eq $default; $nopush = 1 if $_ eq 'unknown'; } unless ($found) { push(@$values, 'unknown') unless $nopush; $default = 'unknown'; } Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Categories containing "++" make gnatsweb crash 2003-05-05 17:48 ` Lars Henriksen @ 2003-05-06 9:31 ` Yngve Svendsen 2003-05-06 21:13 ` Yngve Svendsen 1 sibling, 0 replies; 5+ messages in thread From: Yngve Svendsen @ 2003-05-06 9:31 UTC (permalink / raw) To: Lars Henriksen; +Cc: 'help-gnats@gnu.org', Dieperink Alwin At 19:45 05.05.2003 +0200, Lars Henriksen wrote: >I agree that assumptions about characters should be avoided and that the >foreach-construction does this, but please lecture me: is perl-grep >particularly expensive?. I would assume grep is a bit more expensive than the foreach construct, since it builds and returns a list of matched values. However, the primary reason I changed over to a foreach construct is conceptual, I simply don't like using a function (grep) that returns a value which is then simply thrown away. >I have another comment, though. If the field value isn't a known enumeration >value, the value 'unknown' is inserted in the enumeration array and made >the default value for display. But in my original code the insertion of >'unknown' only happened if it wasn't already there (the second grep operation >above). The reason is that 'unknown' may be a perfectly valid enumeration >value (and if it is already there, we don't want to insert it a second time). Good point. I will look at the patch and most likely apply it. - Yngve _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Categories containing "++" make gnatsweb crash 2003-05-05 17:48 ` Lars Henriksen 2003-05-06 9:31 ` Yngve Svendsen @ 2003-05-06 21:13 ` Yngve Svendsen 1 sibling, 0 replies; 5+ messages in thread From: Yngve Svendsen @ 2003-05-06 21:13 UTC (permalink / raw) To: Lars Henriksen; +Cc: 'help-gnats@gnu.org' At 19:45 05.05.2003 +0200, Lars Henriksen wrote: >I have another comment, though. If the field value isn't a known enumeration >value, the value 'unknown' is inserted in the enumeration array and made >the default value for display. But in my original code the insertion of >'unknown' only happened if it wasn't already there (the second grep operation >above). The reason is that 'unknown' may be a perfectly valid enumeration >value (and if it is already there, we don't want to insert it a second time). >E.g. I have the following entry in the responsible file: > >unknown:The name is not in the responsible file - use "view" to see >it.:gnats-admin > >If you edit a PR with an unknown responsible, the descriptive text is then >diplayed as a guide to the user. > >Here is a suggestion for a modified foreach-loop: (snip) Committed both to the head and v4-0 branches. - Yngve _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-05-06 21:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-01-20 14:34 Categories containing "++" make gnatsweb crash Dieperink Alwin 2003-04-29 19:47 ` Yngve Svendsen 2003-05-05 17:48 ` Lars Henriksen 2003-05-06 9:31 ` Yngve Svendsen 2003-05-06 21:13 ` Yngve Svendsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).