From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SjLKF-0002c3-1C for mharc-grub-devel@gnu.org; Mon, 25 Jun 2012 22:16:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjLKA-0002br-F8 for grub-devel@gnu.org; Mon, 25 Jun 2012 22:16:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjLK7-0001T8-Cq for grub-devel@gnu.org; Mon, 25 Jun 2012 22:16:14 -0400 Received: from qmta03.westchester.pa.mail.comcast.net ([76.96.62.32]:36144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjLK7-0001R0-8I for grub-devel@gnu.org; Mon, 25 Jun 2012 22:16:11 -0400 Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id Sn6s1j0050mv7h053qG9EB; Tue, 26 Jun 2012 02:16:09 +0000 Received: from [192.168.1.101] ([24.63.69.222]) by omta11.westchester.pa.mail.comcast.net with comcast id SqG61j01a4nkFao3XqG7el; Tue, 26 Jun 2012 02:16:07 +0000 Message-ID: <4FE91B67.104@comcast.net> Date: Mon, 25 Jun 2012 22:16:07 -0400 From: Robert Mabee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Release of 2.00~rc1 References: <4FE62E30.7080608@gmail.com> <4FE6C1DF.9050000@comcast.net> <4FE8AC8F.4010806@gmail.com> In-Reply-To: <4FE8AC8F.4010806@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.96.62.32 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 02:16:17 -0000 On 06/25/2012 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 24.06.2012 09:29, Robert Mabee wrote: > >> Missed this one, where the symbol belongs to some other interface, >> but has a value close enough to require an insane test (a filename >> containing a newline) to get incorrect results: >> >> === modified file 'grub-core/commands/wildcard.c' >> --- old/grub-core/commands/wildcard.c 2012-06-08 20:54:21 +0000 >> +++ new/grub-core/commands/wildcard.c 2012-06-24 06:55:33 +0000 >> @@ -153,7 +153,7 @@ >> buffer[i] = '\0'; >> grub_dprintf ("expand", "Regexp is %s\n", buffer); >> >> - if (regcomp (regexp, buffer, RE_SYNTAX_GNU_AWK)) >> + if (regcomp (regexp, buffer, REG_EXTENDED)) >> { >> grub_free (buffer); >> return 1; >> > REG_EXTENDED isn't even a syntax type but is just refined to 1. Valid > syntaxes are: > > RE_SYNTAX_EMACS > RE_SYNTAX_AWK > RE_SYNTAX_GNU_AWK RE_SYNTAX_POSIX_AWK RE_SYNTAX_GREP > RE_SYNTAX_EGREP RE_SYNTAX_POSIX_EGREP RE_SYNTAX_ED > RE_SYNTAX_SED > RE_SYNTAX_POSIX_BASIC RE_SYNTAX_POSIX_MINIMAL_BASIC > RE_SYNTAX_POSIX_EXTENDED RE_SYNTAX_POSIX_MINIMAL_EXTENDED > > Additionally no real testcase was ever demonstrated. Looking at the code and "man regex" (not binding on Grub, but describes the code that was imported), it appears regcomp takes the OR of any of REG_EXTENDED, REG_ICASE, REG_NEWLINE, REG_NOSUB, all defined by POSIX. RE_SYNTAX_* are valid args to re_set_syntax or re_compile_internal, defined by GNU. RE_SYNTAX_GNU_AWK happens to have the bits REG_EXTENDED, REG_NEWLINE, and REG_NOSUB set. The last has no effect because wildcard.c doesn't pass the array to collect subexpression matches. REG_EXTENDED is usually used because the alternative ("basic") syntax is called obsolete. However, the basic syntax has many fewer special characters so would save code (to quote them) in wildcard.c. Probably REG_ICASE should be set according to the fs case insensitivity. REG_NEWLINE causes incorrect results when a filename contains a newline, both because a wild char won't match the newline, and because the generated pattern anchors ^$ can match adjacent to the newline. For example, after echo foo >'/foo bar' (shell, OS, fs permitting) Grub will fail to show this file with ls /f*r but will show it with /*o or /b* (as well as the expected /*r and /f*). I support your choice not to include this in a code freeze, since it is so unlikely to affect anyone. I only wanted to make sure it didn't get lost.