Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> > - Processing in unibyte locales should not become significantly slower
>> > than before.
>> > - Code duplication should be avoided, for maintainability.
>> > - Macros which expand to one thing in the multibyte case and to another
>> > thing for the unibyte case are not acceptable.
>> >
>> > How will this students' project solve this dilemma?
>>
>> There's no guarantee, but Paul and I will be supervising.
>
> I mean, what is technically the solution to the dilemma? The typical idiom
> for keeping the speed of the unibyte case is - see e.g.
> gnulib/lib/mbscasecmp.c
> as an example -
>
> #if HAVE_MBRTOWC
> if (MB_CUR_MAX > 1)
> ... multibyte case ...
> else
> #endif
> ... unibyte case ...
>
> but it does have code duplication.
Right. That is the problem.
When it's just a couple lines, it's not a big deal, but when each of 10
or more programs ends up with duplicated blocks of core logic, it's
much harder to justify.
> What approach are they going after? Put a big
>
> switch (c)
> {
> case 'A'..'Z':
> ... handle printable ASCII characters ...
> default:
> ... handle multibyte case ...
> }
>
> into every loop? This approach has not even sufficed for lib/mbswidth.c.
>
> Do they want to speed up the multibyte case code by some tricks?
>
> Or are you giving up one of the three requirements? If so, which one?
I'm open to all reasonable solutions, especially when accompanied
with sample code.
BTW, your #3 looks like something written (or paraphrased?) by you, not me:
> - Macros which expand to one thing in the multibyte case and to another
> thing for the unibyte case are not acceptable.
That does ring a faint bell, but I don't have time to dig right now.
Do you recall the context?
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
