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 <[email protected]> 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
