Re: iconv "versions"

vallor wrote this copyrighted missive and expects royalties:

On Thu, 14 Mar 2024 23:23:30 -0000 (UTC), vallor <vallor@cultnix.org>
wrote in <ut00ti$1qbd1$1@dont-email.me>:
>

On Thu, 14 Mar 2024 16:48:08 -0400, Chris Ahlstrom
<OFeem1987@teleworm.us>
wrote in <usvnq9$1r7ed$1@dont-email.me>:
 

So I'm writing code that calls iconv(3), and it's reading a file
encoded in an ISO-8859-1 character set and converting to UTF-8, and it
keeps complaining about "invalid multibyte sequence".
 
I'm pounding my head trying to debug the issue, goo-goo'ing for related
issues,
even trying a different implemenation.
 
I give up, commit the code to my home "server" on the "Ubuntu" laptop.
 
Later, I fire up the "Arch" laptop, pull the code, build it, run it,
and run the test script. No problem!
 
Although no version info appears in "man 3 iconv", the text is
different, so something changed.
 
Them damn GNU libraries! :-D
 
At least it got me to write a slightly better conversion function,
based on the "recode()" function in the Fluxbox code base.

 
Running iconv(1) with the "--version" option gives some information.
 
Could that clear up the mystery?

>
BTW, Chris...you weren't reinventing the iconv(1) tool, were you? *<:-)

No, just using it in a library project derived from tinygettext.
I macro-disabled the original use of iconv and replaced it with an
enhanced version of the recode() function from the Fluxbox project
on GitHub.

There's nothing that would convince me to reimplement iconv.  If you want to
see a real morass, just look at the gettext-related code in GNU's glibc.

--
Be security conscious -- National defense is at stake.