Paul Eggert wrote:
> On 10/10/11 01:03, Paolo Bonzini wrote:
>
>> The reason is that then MB_CUR_MAX would be inconsistent with the
>> behavior of mbrlen and similar functions.
>
> Surely it's OK if MB_CUR_MAX is larger than it strictly needs to be.
> I can't think of any application that would break if MB_CUR_MAX
> were set to MB_LEN_MAX on ancient hosts that lacked MB_CUR_MAX.
I agree.
Remember the code we're talking about here (from src/mbsupport.h):
#if defined HAVE_WCSCOLL && defined HAVE_ISWCTYPE
# define MBS_SUPPORT 1
#else
# define MBS_SUPPORT 0
#endif
#if ! MBS_SUPPORT
# undef MB_CUR_MAX
# define MB_CUR_MAX 1
#endif
That #undef is used only on relatively old systems that lack the
required support. And with MBS_SUPPORT/MB_CUR_MAX == 0/1, uses
of multi-byte functions like mbrlen should be #if'd or compiled out.
Without an actual failure (or at least a more plausible argument),
adding a symbol like GREP_MB_CUR_MAX feels unjustified.
