Thanks for putting this together, it'll be great to have an OSS version of this tool. While there are some nits, I've tried to distinguish between things that are problems and not by using the issue flag (some of the shell style, for example).
There's one additional comment: This is missing an entry in the closed-bins exception list.

It might be nice to include Makefile.ctf and build this with ctf support to make debugging easier.

cstyle looks wrong here.

This doesn't seem to be used, remove it?

Conventionally these should have structure prefixes.

Maybe we should use abort instead of assert(0) to make sure that in the case someone ever turns off asserts, it still blows up?

Since where isn't used anywhere in this function, it's allowed to be NULL, so you can optionally drop where.

Can you add a comment about why it's safe to free ssym and esym here? That'll help folks who are going through understand this better.
At first glance, it's quite weird to see the thing that's not allocating it freeing it, though I suspect that's because we're integrating with yacc here.

Probably worth a comment here indicating that it's designed to try and find a subset match. At first I was surprised to see the iteration around len.

Is there a reason this is harcoded as opposed to doing something like basename(argv[0]) in main() right away?

It seems worth including the sterror here that indicates why the iconv_open() failed, as otherwise it'll be hard for users to get a sense of what went wrong.

I notice that you're using an off64_t, but I don't see anything that indicates that the rest of this is using 64-bit offset capable functions. Should this actually be being built with large file support?

Has this been tested with files that need that off64_t?

Can you add a comment regarding why it's safe to write this out before we check errno? It seems like we're relying on the downstream callers to never change oleft at all in error, which I'm not sure is guaranteed by iconv(3C), for example.

cstyle

Was reminder supposed to be remainder?

I think we're guaranteed that this doesn't overlap, is that right? Otherwise, we may want to use memmove() to be safe.

cstyle

cstyle

cstyle

Isn't this meant to be iconv_errno? Couldn't errno have changed? due to other callers?

What's the point of the perror here given the line above? Won't errno also have been potentially clobbered at this point through the fprintf, etc.?

Why do we ignore the fwrite failures here? Shouldn't that be fatal like the ones earlier?

While the script doesn't feel that appropriate (but it's what we have for now), the error handling is inappropriate.

We need to at least indicate errors that happened. Otherwise this will silently fail and exit 0, causing users to think that there's nothing there!

We presumably need to unalias things.

General illumos scripting style has traditionally had the do statement on the line with the while/flor.

Looks like this whitespace isn't consistent with the rest.

General illumos scripting style has traditionally had the do statement on the line with the while/flor.

Looks like this whitespace isn't consistent with the rest.

General illumos scripting style has traditionally had the do statement on the line with the while/flor.

Do we need to be checking for strdup failure here or is that being done elsewhere? If the latter, can the comment indicate where it's actually checked?

It appears that warnings is only ever set? Was it supposed to be used as part of determining some part of the exit status?

For this to work, do we need to depend on the packages that have the iconv modules that are being used in the tests?

The follow ups here all look pretty reasonable. Though there are still some outstanding questions in the back and forth that I'd like to make sure are straightened out before I sign off.

In general, this looks good. A couple minor questions on this, but should be able to wrap this up and integrate it. Thanks again for helping replace the closed bins!

I think we also need the _LARGEFILE_SOURCE macro set here.

Cast to void or handle for lint? Same with the other printf calls in this function.

Is a 256 byte dirent large enough? Should we instead be using a constant? dirent.h(3HEAD) seems to refer to NAME_MAX, while head/dirent.h seems to have a MAXNAMELEN of 512? I guess it's unlikely to matter immediately.

Should we worry about truncation or just case to void?

Ship It!

closed source iconv has better error message in case the supplied conversion is invalid:
altair:yuri:~$ echo привет | iconv -t utf64

Not supported UTF-8 to utf64

altair:yuri:~$ echo привет | ~/ws/il-iconv/proto/root_i386/usr/bin/iconv -t utf64

iconv_open failed: Invalid argument

altair:yuri:~$

nitpicking (really) - iconv -l has a trailing comma on the last line

Ship It!