Hi! Re this:
Date: Thu, 19 Aug 2010 13:16:56 +0000
Subject: Fwd: What's cooking in git.git (Aug 2010, #04; Wed, 18)
From: ??var Arnfj??r?? Bjarmason <redacted>
To: "Arnold D. Robbins" <redacted>
Hi there. The Git project grabbed the gawk regex engine to use as a
compat engine in case the platform we're working on doesn't support
REG_STARTEND. But because we don't compile it with RE_ENABLE_I18N
it'll spew some warnings about unused variables (see below). Here's a
patch to solve this:
Wow! It's really cool to be upstream for someone else. :-)
Thanks for the patch. I'll get it into my code base.
I was going to report this upstream once I got around to finding out
what upstream *is*, I don't *think* gawk itself is the canonical
upstream, they just copy it from somewhere else (again, I *think*).
About every year or so, I sync from whatever is in GLIBC. But my version
has a number of additional fixes that have not been accepted back into
the GLIBC version.
The only other possible candidate for an "upstream" source would be the
version in gnulib.
HTH,
Arnold
Wrap variables that were only used RE_ENABLE_I18N in `#ifdef
RE_ENABLE_I18N`. This eliminates compiler warnings when compiling with
NO_REGEX=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
On Thu, Aug 19, 2010 at 18:05, Aharon Robbins [off-list ref] wrote:
Hi! Re this:
quoted
Date: Thu, 19 Aug 2010 13:16:56 +0000
Subject: Fwd: What's cooking in git.git (Aug 2010, #04; Wed, 18)
From: ??var Arnfj??r?? Bjarmason <redacted>
To: "Arnold D. Robbins" <redacted>
Hi there. The Git project grabbed the gawk regex engine to use as a
compat engine in case the platform we're working on doesn't support
REG_STARTEND. But because we don't compile it with RE_ENABLE_I18N
it'll spew some warnings about unused variables (see below). Here's a
patch to solve this:
Wow! It's really cool to be upstream for someone else. :-)
Cool that someone else is teasing useful code out of glibc so I don't
have to :)
Thanks for the patch. I'll get it into my code base.
Junio, here's a version of this patch for our tree.
quoted
I was going to report this upstream once I got around to finding out
what upstream *is*, I don't *think* gawk itself is the canonical
upstream, they just copy it from somewhere else (again, I *think*).
About every year or so, I sync from whatever is in GLIBC. But my version
has a number of additional fixes that have not been accepted back into
the GLIBC version.
The only other possible candidate for an "upstream" source would be the
version in gnulib.
That's good to know. B.t.w. we have to compile with -DNO_MBSUPPORT
because regex_internal.h will pull in mbsupport.h if it's defined,
which is a GPLv3 header, the rest being LGPL 2.1.
I don't even know if we want mbsupport.h, but if it's possible to
relicense mbsupport.h to LGPL 2.1 it'd be easier for projects like Git
to pull in the gawk regex engine.
compat/regex/regex_internal.c | 2 +-
compat/regex/regexec.c | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/compat/regex/regex_internal.c b/compat/regex/regex_internal.c
index dad17a8..193854c 100644
--- a/compat/regex/regex_internal.c
+++ b/compat/regex/regex_internal.c
@@ -692,10 +692,10 @@ re_string_reconstruct (re_string_t *pstr, int idx, int eflags)
}
else
{
+#ifdef RE_ENABLE_I18N
/* No, skip all characters until IDX. */
int prev_valid_len = pstr->valid_len;
-#ifdef RE_ENABLE_I18N
if (BE (pstr->offsets_needed, 0))
{
pstr->len = pstr->raw_len - idx + offset;diff --git a/compat/regex/regexec.c b/compat/regex/regexec.c
index aee502d..0c2b054 100644
--- a/compat/regex/regexec.c
+++ b/compat/regex/regexec.c
@@ -3059,7 +3059,9 @@ check_arrival_add_next_nodes (re_match_context_t *mctx, int str_idx,
const re_dfa_t *const dfa = mctx->dfa;
int result;
int cur_idx;
+#ifdef RE_ENABLE_I18N
reg_errcode_t err = REG_NOERROR;
+#endif
re_node_set union_set;
re_node_set_init_empty (&union_set);
for (cur_idx = 0; cur_idx < cur_nodes->nelem; ++cur_idx)
--
1.7.2.1.446.g168052