Re: coreutils and i18n

[Jim Meyering]

Bruno Haible <address@hidden> 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?