bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/5] maint: ensure that MB_CUR_MAX is defined even when !MBS_


From: Aharon Robbins
Subject: Re: [PATCH 1/5] maint: ensure that MB_CUR_MAX is defined even when !MBS_SUPPORT
Date: Sun, 02 Oct 2011 21:32:39 +0200
User-agent: Heirloom mailx 12.4 7/29/08

Hi. Just now catching up on email...

> Date: Fri, 16 Sep 2011 15:12:37 +0200
> From: Paolo Bonzini <address@hidden>
> To: address@hidden
> CC: address@hidden
> Subject: Re: [PATCH 1/5] maint: ensure that MB_CUR_MAX is defined even when
>  !MBS_SUPPORT
>
> On 09/16/2011 03:03 PM, address@hidden wrote:
> > Please remember that dfa.[ch] are shared code with gawk and I think
> > also gettext (although I don't know how up to date gettext's version is).
> >
> > I'd really prefer not to have too many GREP_xxx kinds of things in those
> > files.  (It's ok in the rest of grep, of course.:-)
>
> We could separate the variables for dfa and the rest of grep.  Grep just 
> needs "#define DFA_MB_CUR_MAX GREP_MB_CUR_MAX" then (and you can 
> similarly "#define DFA_MB_CUR_MAX gawk_mb_cur_max" in gawk).

Yeah. Maybe with a separate header to hide the gory details.

> Having variables grep_mb_cur_max and dfa_mb_cur_max (separate for the 
> reasons Arnold explained) would work, but it would make it impossible 
> for the compiler to throw away the multibyte code when MBS_SUPPORT is zero.

Why?

#if MBS_SUPPORT
int greb_mb_cur_max = MB_CUR_MAX; /* or initialize it in main */
#else
#define grep_mb_cur_max 1
#endif

Hmmm.  Maybe I should try a proof-of-concept for this in gawk... :-)

Thanks,

Arnold



reply via email to

[Prev in Thread] Current Thread [Next in Thread]