[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build failure when system does not provide MB_CUR_MAX

From: Bruno Haible
Subject: Re: build failure when system does not provide MB_CUR_MAX
Date: Wed, 27 May 2009 00:40:23 +0200
User-agent: KMail/1.9.9

Mike Frysinger wrote:
> i dont see any checks/replacements for when MB_CUR_MAX does not exist

This is because MB_CUR_MAX is part of ANSI C + amendment 1 (ca. 1995), and
no platforms are known that lack it (see gnulib/doc/posix-headers/stdlib.texi).

Likewise for mbtowc(): It's present on all platforms we care about, see

> (like in a uClibc build where all multibyte  
> related stuff has been disabled).  for example, zile falls apart like so:
> ../../zile-2.3.7/lib/mbrtowc.c: In function ‘rpl_mbrtowc’:
> ../../zile-2.3.7/lib/mbrtowc.c:96: warning: implicit declaration of function 
> ‘mbtowc’
> ../../zile-2.3.7/lib/mbrtowc.c:124: error: ‘MB_CUR_MAX’ undeclared (first use 
> in this function)

There is an easy way out: just don't disable all multibyte related stuff
in uClibc.

uClibc has this code, that's what you're saying. Therefore there's no point
in gnulib to duplicate this functionality. All other platforms have
ANSI C + amendment 1.

> after all, gnulib is providing the multibyte functions itself

No, gnulib is not providing the whole locale and multibyte layer from
scratch. It provides the reasonable set of multibyte functions, assuming
the foundations are already implemented in the system libc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]