threads / patch / 58365

v4grep: fix multibyte regex handling under macOS

Subject: [PATCH v4] grep: fix multibyte regex handling under macOS

## tl;dr

4 messages between Aug 26, 2022 and Sep 13, 2022. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Diomidis Spinellis· Aug 26, 2022, 08:58 UTC · lore

The commit 29de20504e (Makefile: fix default regex settings on Darwin, 2013-05-11) fixed t0070-fundamental.sh under Darwin (macOS) by adopting Git's regex library. However, this library is compiled with NO_MBSUPPORT, which causes git-grep to work incorrectly on multibyte (e.g. UTF-8) files. Current macOS versions pass t0070-fundamental.sh with the native macOS regex library, which also supports multibyte characters.

Adjust the Makefile to use the native regex library, and call setlocale(3) to set CTYPE according to the user's preference. The setlocale call is required on all platforms, but in platforms supporting gettext(3), setlocale was called as a side-effect of initializing gettext. Therefore, move the CTYPE setlocale call from gettext.c to common-main.c and the corresponding locale.h include into git-compat-util.h.

Thanks to the global initialization of CTYPE setlocale, the test-tool regex command now works correctly with supported multibyte regexes, and is used to set the MB_REGEX test prerequisite by assessing a platform's support for them.

Signed-off-by: Diomidis Spinellis <dds@aueb.gr>
---
- Fold test script into t7810-grep.sh
- Simplify the test prerequisite evaluation
 Makefile          |  2 +-
 common-main.c     |  1 +
 gettext.c         |  2 --
 git-compat-util.h |  1 +
 t/t7810-grep.sh   | 15 +++++++++++++++
 5 files changed, 18 insertions(+), 3 deletions(-)
Show changes to 5 files +18 −3

Makefile, common-main.c, gettext.c, git-compat-util.h, t/t7810-grep.sh

diff --git a/Makefile b/Makefile
index 04d0fd1fe6..d1a9825715 100644
--- a/Makefile
+++ b/Makefile
@@ -1427,7 +1427,6 @@ ifeq ($(uname_S),Darwin)
 		APPLE_COMMON_CRYPTO = YesPlease
 		COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
 	endif
-	NO_REGEX = YesPlease
 	PTHREAD_LIBS =
 endif
 
@@ -2970,6 +2969,7 @@ GIT-BUILD-OPTIONS: FORCE
 	@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@+
 	@echo NO_PTHREADS=\''$(subst ','\'',$(subst ','\'',$(NO_PTHREADS)))'\' >>$@+
 	@echo NO_PYTHON=\''$(subst ','\'',$(subst ','\'',$(NO_PYTHON)))'\' >>$@+
+	@echo NO_REGEX=\''$(subst ','\'',$(subst ','\'',$(NO_REGEX)))'\' >>$@+
 	@echo NO_UNIX_SOCKETS=\''$(subst ','\'',$(subst ','\'',$(NO_UNIX_SOCKETS)))'\' >>$@+
 	@echo PAGER_ENV=\''$(subst ','\'',$(subst ','\'',$(PAGER_ENV)))'\' >>$@+
 	@echo DC_SHA1=\''$(subst ','\'',$(subst ','\'',$(DC_SHA1)))'\' >>$@+
diff --git a/common-main.c b/common-main.c
index c531372f3f..0a22861f1c 100644
--- a/common-main.c
+++ b/common-main.c
@@ -40,6 +40,7 @@ int main(int argc, const char **argv)
 
 	git_resolve_executable_dir(argv[0]);
 
+	setlocale(LC_CTYPE, "");
 	git_setup_gettext();
 
 	initialize_the_repository();
diff --git a/gettext.c b/gettext.c
index bb5ba1fe7c..f139008d0a 100644
--- a/gettext.c
+++ b/gettext.c
@@ -10,7 +10,6 @@
 #include "config.h"
 
 #ifndef NO_GETTEXT
-#	include <locale.h>
 #	include <libintl.h>
 #	ifdef GIT_WINDOWS_NATIVE
 
@@ -80,7 +79,6 @@ static int test_vsnprintf(const char *fmt, ...)
 
 static void init_gettext_charset(const char *domain)
 {
-	setlocale(LC_CTYPE, "");
 	charset = locale_charset();
 	bind_textdomain_codeset(domain, charset);
 
diff --git a/git-compat-util.h b/git-compat-util.h
index 58d7708296..c6fa3c7469 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -212,6 +212,7 @@
 #endif
 #include <errno.h>
 #include <limits.h>
+#include <locale.h>
 #ifdef NEEDS_SYS_PARAM_H
 #include <sys/param.h>
 #endif
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 6935601171..308a3dc231 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -18,6 +18,9 @@ test_invalid_grep_expression() {
 	'
 }
 
+LC_ALL=en_US.UTF-8 test-tool regex '^.$' '¿' &&
+  test_set_prereq MB_REGEX
+
 cat >hello.c <<EOF
 #include <assert.h>
 #include <stdio.h>
@@ -87,6 +90,10 @@ test_expect_success setup '
 		echo unusual >"\"unusual\" pathname" &&
 		echo unusual >"t/nested \"unusual\" pathname"
 	fi &&
+	if test_have_prereq MB_REGEX
+	then
+		echo "¿" >reverse-question-mark
+	fi &&
 	git add . &&
 	test_tick &&
 	git commit -m initial
@@ -568,6 +575,14 @@ do
 	'
 done
 
+test_expect_success MB_REGEX 'grep exactly one char in single-char multibyte file' '
+	LC_ALL=en_US.UTF-8 git grep "^.$" reverse-question-mark
+'
+
+test_expect_success MB_REGEX 'grep two chars in single-char multibyte file' '
+	LC_ALL=en_US.UTF-8 test_expect_code 1 git grep ".." reverse-question-mark
+'
+
 cat >expected <<EOF
 file
 EOF
-- 
2.30.2
Junio C Hamano· Sep 13, 2022, 17:32 UTC · re: Diomidis Spinellis · lore

Re: [PATCH v4] grep: fix multibyte regex handling under macOS

Diomidis Spinellis <dds@aueb.gr> writes:
> - Fold test script into t7810-grep.sh
> - Simplify the test prerequisite evaluation

The tests certainly look better, and as v3, the build procedure sounds OK.

Show 25 quoted lines
> diff --git a/common-main.c b/common-main.c
> index c531372f3f..0a22861f1c 100644
> --- a/common-main.c
> +++ b/common-main.c
> @@ -40,6 +40,7 @@ int main(int argc, const char **argv)
>  
>  	git_resolve_executable_dir(argv[0]);
>  
> +	setlocale(LC_CTYPE, "");
>  	git_setup_gettext();
>  
>  	initialize_the_repository();
> ...
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 58d7708296..c6fa3c7469 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -212,6 +212,7 @@
>  #endif
>  #include <errno.h>
>  #include <limits.h>
> +#include <locale.h>
>  #ifdef NEEDS_SYS_PARAM_H
>  #include <sys/param.h>
>  #endif

I'll let others more familiar with the locale support to comment on these changes. We are unconditionally including <locale.h> now; platforms that lack <locale.h> could set NO_GETTEXT to work it around before this change, but that will no longer work.

I do not know if thta is a practical downside to anybody, but it could be a problem.

Perhaps cook this in 'next' and see if anybody screams?
Thanks.
Diomidis Spinellis· Sep 13, 2022, 18:09 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] grep: fix multibyte regex handling under macOS

On 13-Sep-22 20:32, Junio C Hamano wrote:
Show 14 quoted lines
>> +#include <locale.h>
>>   #ifdef NEEDS_SYS_PARAM_H
>>   #include <sys/param.h>
>>   #endif
> 
> I'll let others more familiar with the locale support to comment on
> these changes.  We are unconditionally including <locale.h> now;
> platforms that lack <locale.h> could set NO_GETTEXT to work it
> around before this change, but that will no longer work.
> 
> I do not know if thta is a practical downside to anybody, but it
> could be a problem.
> 
> Perhaps cook this in 'next' and see if anybody screams?

I was programming in C before locale.h was introduced, so its availability was something that worried me as well. I looked up whether we could/should use a GNU autoconf macro to test for the locale.h availability. According to autoconf's documentation "All hosted environments that are still of interest for portable code provide all of the headers specified in ISO C90 (as amended in 1995): assert.h, [...] locale.h [...], and wctype.h. Most programs can safely include these headers unconditionally." [1]

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.70/autoconf.html
Junio C Hamano· Sep 13, 2022, 20:41 UTC · re: Diomidis Spinellis · lore

Re: [PATCH v4] grep: fix multibyte regex handling under macOS

Diomidis Spinellis <dds@aueb.gr> writes:
>> Perhaps cook this in 'next' and see if anybody screams?
Let's do this.
Show 8 quoted lines
> I was programming in C before locale.h was introduced, so its
> availability was something that worried me as well.  I looked up
> whether we could/should use a GNU autoconf macro to test for the
> locale.h availability.  According to autoconf's documentation "All
> hosted environments that are still of interest for portable code
> provide all of the headers specified in ISO C90 (as amended in 1995):
> assert.h, [...] locale.h [...], and wctype.h. Most programs can safely
> include these headers unconditionally." [1]

Yeah, but there are folks on minor platforms where full POSIX compliance is iffy, so whatever autoconf's documentation says unfortunately does not weigh as much as we wish it does.

← back to recent threads