Jim Meyering wrote:
> I'm open to all reasonable solutions, especially when accompanied
> with sample code.
This is the proposed sample code: the 'expand' program. Here the core
of the program is in the single function expand(). The proposed solution is
like this. It uses a set of macros, which -
Bruno Haible 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 fo
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
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
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> As for i18n, some students nearly took on the project of implementing a
>> palatable solution recently, but that's been deferred for a few months.
>
> Interesting... In 2001 you set out the following requirements for such
> a solution
Jim Meyering wrote:
> As for i18n, some students nearly took on the project of implementing a
> palatable solution recently, but that's been deferred for a few months.
Interesting... In 2001 you set out the following requirements for such
a solution:
- Processing in unibyte locales should not be
