Re: proposed patch to dfa.c

[Paul Eggert]

Thanks for catching that.  I pushed the following, which uses
&& rather than ? : but has the same underlying logic.

That identifier "is_valid_unibyte_character" is confusing, and this
confusion perhaps contributed to the bug.  The predicate doesn't
really mean "C is a valid unibyte character"; it really means
"it won't mess up the word-constituent test if you pass C
to isalnum".  Maybe we should rename it at some point...

>From 1e83f7f353219be88339032d9e21dbef1f64108e Mon Sep 17 00:00:00 2001
From: Paul Eggert <address@hidden>
Date: Thu, 12 Jan 2012 12:50:04 -0800
Subject: [PATCH] dfa: non-glibc word-constituent unibyte fix

* src/dfa.c (is_valid_unibyte_character): Fix typo that caused
this to incorrectly return 0 on unibyte non-glibc systems.
Problem reported by Aharon Robbins in
<http://lists.gnu.org/archive/html/bug-grep/2012-01/msg00084.html>.
---
 src/dfa.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/dfa.c b/src/dfa.c
index 8dbadd5..6ab0ab4 100644
--- a/src/dfa.c
+++ b/src/dfa.c
@@ -1079,7 +1079,7 @@ parse_bracket_exp (void)
 #ifdef __GLIBC__
 # define is_valid_unibyte_character(c) 1
 #else
-# define is_valid_unibyte_character(c) (MBS_SUPPORT && btowc (c) != WEOF)
+# define is_valid_unibyte_character(c) (! (MBS_SUPPORT && btowc (c) == WEOF))
 #endif
 
 /* Return non-zero if C is a `word-constituent' byte; zero otherwise.  */
-- 
1.7.6.5