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.
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?
Bruno
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
