This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: MB_LEN_MAX conflict between gcc's limits.h and newlib's sys/config.h
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, newlib at sources dot redhat dot com
- Date: Mon, 09 Sep 2002 08:48:51 +0100
- Subject: Re: MB_LEN_MAX conflict between gcc's limits.h and newlib's sys/config.h
- Organization: SuperH UK Ltd.
- References: <3D78BB45.E652F991@superh.com> <3D78D1F8.D32BA3C8@redhat.com>
"J. Johnston" wrote:
> The second issue is that the gcc default value does not consider that multibyte
> support may exist. According to ANSI, the value of MB_CUR_MAX (which
> is found in stdlib.h) is never larger than MB_LEN_MAX. This isn't true
> as MB_CUR_MAX can be set up to 8 for Japanese JIS, for example, when
> newlib is configured with the --enable-newlib-mb option. Perhaps gcc
> could look for this configuration option when building a cross-compiler and
> set MB_LEN_MAX appropriately.
gcc's limits.h generation has a check if there is a target limits.h header,
and if so, that is included first, and MB_LEN_MAX is only defined by gcc's limits.h
if it hasn't been defined before by the target.
But for this to work, newlib would have to have a limits.h file to start with, and
gcc would have to find it in $(SYSTEM_HEADER_DIR) .
--
--------------------------
SuperH (UK) Ltd.
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330