Re: questions about new multibyte character support in EGCS/GCC2

[Paul Eggert <eggert at twinsun dot com>]

   Date: Mon, 07 Dec 1998 11:42:00 -0500
   From: Dave Brolley <brolley@cygnus.com>

   > * It appears to me that the multibyte lexing code could be sped up quite
   >   a bit by using the draft C9x multibyte functions, if available.  Any
   >   thoughts before I start hacking in this direction?

   As long as things still work where these functions are not
   available, then I think it's preferable to use the actual functions
   where possible.

Sounds good, but there is a corollary.  For performance reasons, the
GCC multibyte code should invoke the actual multibyte functions
directly, instead of via an intermediary.  E.g. the code should invoke
mblen directly, instead of having local_mblen invoke mblen.  This is
because these functions are often implemented inline for speed, and
introducing an intermediary kills this performance optimization.  (The
GNU C library uses tricks like this.)

GCC should use local_mblen etc. only on translation hosts that don't
have proper multibyte functions.  I'll look into making this
performance optimization.  The documentation would have to be changed
slightly: it would say that e.g. LANG='C-EUCJP' is supported only on
hosts that don't have proper localization, and that if you're on, say,
Solaris you should do as the Solarians do and use LANG='ja'.  I don't
think this will be much of a problem, as it's standard practice.

Also, by the way, cpplib should not invoke mblen either directly or
indirectly, since mblen is not reentrant.  It should invoke mbrlen
instead, if available.  It might be more convenient to make the
local_* multibyte functions reentrant too.  I guess I'll look into
doing this as well...