Subject: Re: iconv and errno
To: None <tech-userlevel@netbsd.org>
From: Jason Thorpe <thorpej@shagadelic.org>
List: tech-userlevel
Date: 04/24/2005 10:09:14
On Apr 24, 2005, at 5:09 AM, James K. Lowden wrote:

> Having recently installed NetBSD 2.0, I was happy to start using our
> native iconv instead of GNU's.  I think the error messages it  
> produces,
> though, are misleading.
>
> I prepared a patch (my first ever).
>
> Problems as I see them:
>
> 1.    $ echo 'hi' | iconv -t asdf -f ucs-2le
>     iconv: iconv_open(asdf, ucs-2le): No such file or directory

This is indeed a bug in iconv(3), even according to our own man  
page.  Please file a PR on this problem separately.

> 2.    $ echo 'hi' | iconv -t ascii -f ucs-2le
>     iconv: iconv(): Invalid argument
>
> Should say that '\n' at byte 3 is an incorrect or incomplete  
> sequence for
> ucs-2le.

Actually, EINVAL is a valid error code for "incomplete character or  
shift sequence".  However, it would probably be a good idea to file a  
separate PR for this issue so that the NetBSD iconv experts can take  
a look.

> 3.    $ iconv -t ascii -f ucs-2le nosuchfile
>     iconv: iconv: nosuchfile:No such file or directory
>
> Why no space after the last colon?  And, anyway, why "iconv:" twice?
>
> Unfortunately, it seems only some of the trouble is in /usr/bin/iconv.
> Some if it stems from iconv(3).
>
> Remedies:
>
> 1.  /usr/src/lib/libc/iconv/iconv.c::_iconv_open calls  
> _citrus_iconv_open,
> which apparently returns ENOENT if the 'in' or 'out' arguments don't
> exist.  The function sets errno, which iconv(1) duly reports to the  
> poor
> user as "No such file or directory".  That contradicts both the  
> iconv(3)
> man page and, IMHO, good sense.  It should set errno to EINVAL.
>
> 2.  __iconv() returns EINVAL, which is good.  But when iconv(1)  
> calls errx
> with EINVAL, it produces the above message.  If it called errx with
> EILSEQ, you'd see "iconv: iconv(): Illegal byte sequence", which at  
> least
> points the user at the data, instead of the command-line arguments.
>
> 3.  Easy enough, even for me, unless there's some policy I should know
> about?

I checked in the patch for #3.

Thanks.

-- thorpej