Hello, > the attached patch solves two problems with the current version of > m4/wcwidth.m4 (serial 14). However, those two problems are so closely > related that I chose to attack them in one patch.
On which platform did you encounter a wcwidth that does not work? In doc/posix-functions/wcwidth.texi we list known problems on MacOS X. What's your platform? > The first problem arises if the setlocale command fails (returning NULL). > Then the actual test is not executed and the main function returns 0. This > value indicates properly working wcwidth with UTF-8 locale. However, the > test did not take place, as setlocale failed. ... I > sanitized the C programs main return value if setlocale failed. There is a hidden assumption that a system either has many UTF-8 locales, then the test will find the French one, or none at all - and in that case it does not matter how wcwidth behaves with advanced Unicode characters. > The first problem is the hard-coded locale name "fr_FR.UTF-8". I'd suppose > using $LOCALE_FR_UTF8 from gt_LOCALE_FR_UTF8 is a saner choice. In general you're right, but for MacOS X the string "fr_FR.UTF-8" is sufficient. Also, if we're going to fix m4/wcwidth.m4, it would be nice to know your name, for the ChangeLog entry and such. Are you Mario Aistleitner? Bruno
