[Top][All Lists]

[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: Jim Meyering
Subject: Re: [PATCH 1/5] maint: ensure that MB_CUR_MAX is defined even when !MBS_SUPPORT
Date: Fri, 16 Sep 2011 14:51:35 +0200

Paolo Bonzini wrote:

> On 09/16/2011 01:01 PM, Jim Meyering wrote:
>> +
>> +#if ! MBS_SUPPORT
>> +# undef MB_CUR_MAX
>> +# define MB_CUR_MAX 1
>> +#endif
> Thanks for splitting the tail of the series.  I'm still a bit nervous
> about redefining a libc macro.
> What about changing this patch to a sweeping s/MB_CUR_MAX/GREP_MB_MAX/g
> and doing
> instead?

I see no reason to worry about such a redefinition.
A quick look through glibc sources shows that it is only defined
in .h files, never used.  All of the uses in grep/gnulib look fine.
Any code that uses MB_CUR_MAX when MBS_SUPPORT is 0
should be prepared to deal with a "1".
Besides, introducing a new symbol name like that would make the
code slightly less readable.  If a problem arises, and that's
the best solution, I'll be happy to do it, but I would
create/use a new name like that only as a last resort.

> It should be easy to do a global search-and-replace on the patch files
> so that they apply on top of a tree that uses GREP_MB_MAX.
> Also, I am not sure why patch 2/5 is there if it fixes a compilation
> failure, and not at the beginning to prevent the failure?

Indeed, it does not depend on 1/5, so I've pushed it first.

Thanks again for the review.

reply via email to

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