https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124616
--- Comment #11 from James K. Lowden <jklowden at gcc dot gnu.org> --- (In reply to Steve Kargl from comment #10) > James, iconv on FreeBSD uses UTF-32LE instead of UTF32LE. That is some kind of karma. When I added iconv to FreeTDS 20-odd years ago, we struggled with the lack of any standard (afaik) for the names of encodings. What's old is new again, except that now I use Linux instead of NetBSD for development. > diff --git a/libgcobol/charmaps.h b/libgcobol/charmaps.h > index c8fa82264d1..0e17525a7c7 100644 > --- a/libgcobol/charmaps.h > +++ b/libgcobol/charmaps.h > @@ -302,7 +302,11 @@ char * __gg__miconverter(cbl_encoding_t from, > > > #define DEFAULT_SOURCE_ENCODING (iconv_CP1252_e) > +#if __FreeBSD__ > +#define DEFAULT_32_ENCODING (iconv_UTF_32LE_e) > +#else > #define DEFAULT_32_ENCODING (iconv_UTF32LE_e) > +#endif > > class charmap_t; Thank you for that. Will apply. I modified libgcobol today to raise an Exception Condition if iconv_open fails (our first implementation-defined EC, named EC-IMP-ICONV-OPEN). If the user ignores it, life goes on, but any required conversion is not attempted, and the output is zero bytes converted. This I hope will result in failed tests rather core files. If we modify the tests to enable the new EC, they will report that Y cannot be converted from X, and terminate. I think my systematic change needs to wait until gcc-16 is branched, when the development window re-opens. But your patch ISTM qualifies as a bug-fix.
