Hi David,
Until commit 523641d22, that test did a simple check of actual and
expected, regardless of iconv support. Maybe it should have stayed
that way?
Yes, that's the conclusion I've come to.
commit a05f0ee61f14e6d56d065c1e7c050714a687f793
decode_rfc2047(): Stop unused-variable warning if HAVE_ICONV false.
commit d4814561eafc238a9ed2b4fa67ef2755e5e83858
test-charset: Fix test when HAVE_ICONV is false.
When the Content-Type's charset parameter's encoding is `invalid', it
makes no difference whether HAVE_ICONV is defined or not as the
parameter's value can't be decoded.
I don't think GNU iconv eliding question marks, produced by nmh as
`Huh?' output instead of failing, matters here?
I was on the wrong track before because when I looked at config.h,
/* Define to 1 if you have the `getline' function. */
#define HAVE_GETLINE 1
/* Define to 1 if you have the `getutxent' function. */
#define HAVE_GETUTXENT 1
/* Define if you have the iconv() function. */
#define HAVE_ICONV 1
/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
and Makefile,
ICONV_ENABLED = 1
I s/1/0/ for HAVE_ICONV and ICONV_ENABLED. But! Unlike the other
HAVE_... around it, HAVE_ICONV needs to be undefined rather than 0 for
false. In contrast, ICONV_ENABLED must be either 0 or 1, and not empty.
It was simpler to alter m4/iconv.m4 instead.
-AC_CHECK_HEADER([iconv.h],
- [AC_CHECK_FUNC([iconv],
+AC_CHECK_HEADER([iconvxxx.h],
+ [AC_CHECK_FUNC([iconvxxx],
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers