This is a multi-part message in MIME format.

--Multipart=_Sun__24_Apr_2005_08_09_19_-0400_0mkPq3wCK68V6G1J
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Should say that 'asdf' is not a valid encoding name.

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.  

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?  

Patch:

The attached patch exhibits the right behavior, but includes a hack to
workaround the iconv_open(3) problem.  Is it good enough to send-pr?  

--jkl







--Multipart=_Sun__24_Apr_2005_08_09_19_-0400_0mkPq3wCK68V6G1J
Content-Type: application/octet-stream;
 name="iconv.diff"
Content-Disposition: attachment;
 filename="iconv.diff"
Content-Transfer-Encoding: base64

SW5kZXg6IGljb252LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2c3Jvb3Qvc3JjL3Vzci5iaW4v
aWNvbnYvaWNvbnYuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS42CmRpZmYgLXUgLXIxLjYgaWNv
bnYuYwotLS0gaWNvbnYuYwkyMSBEZWMgMjAwNCAxMTozMzowNyAtMDAwMAkxLjYKKysrIGljb252
LmMJMjQgQXByIDIwMDUgMTI6MDM6MzQgLTAwMDAKQEAgLTk2LDcgKzk2LDExIEBACiAJCWZsYWdz
IHw9IF9fSUNPTlZfRl9ISURFX0lOVkFMSUQ7CiAJY2QgPSBpY29udl9vcGVuKHRvLCBmcm9tKTsK
IAlpZiAoY2QgPT0gKGljb252X3QpLTEpCi0JCWVycihFWElUX0ZBSUxVUkUsICJpY29udl9vcGVu
KCVzLCAlcykiLCB0bywgZnJvbSk7CisJCS8qIHdvcmthcm91bmQ6IGljb252KDMpIHNob3VsZCBy
ZXR1cm4gRUlOVkFMIGZvciAKKwkJICogYSBiYWQgdG8vZnJvbS4KKwkJICovCisJCWVycngoRVhJ
VF9GQUlMVVJFLCAiaWNvbnZfb3BlbiglcywgJXMpOiAlcyIsIHRvLCBmcm9tLCAKKwkJCXN0cmVy
cm9yKGVycm5vID09IEVOT01FTT8gRU5PTUVNIDogRUlOVkFMKSk7CiAKIAlpbnZhbGlkcyA9IDA7
CiAJd2hpbGUgKChpbmJ5dGVzID0gZnJlYWQoaW5idWYsIDEsIElOQlVGU0laRSwgZnApKSA+IDAp
IHsKQEAgLTEyNCw5ICsxMjgsOSBAQAogCQkJCQkgICAgSU5CVUZTSVpFLWluYnl0ZXMsIGZwKTsK
IAkJCQlpZiAocmV0ID09IDApIHsKIAkJCQkJaWYgKGZlb2YoZnApKQotCQkJCQkJZXJyeChFWElU
X0ZBSUxVUkUsCi0JCQkJCQkgICAgICJpY29udigpOiAlcyIsCi0JCQkJCQkgICAgIHN0cmVycm9y
KEVJTlZBTCkpOworCQkJCQkJZXJyeChFWElUX0ZBSUxVUkUsIAorCQkJCQkJICAgICAiaWNvbnYo
KTogJXMiLCAKKwkJCQkJCSAgICAgc3RyZXJyb3IoRUlMU0VRKSk7CiAJCQkJCWVsc2UKIAkJCQkJ
CWVycihFWElUX0ZBSUxVUkUsICJmcmVhZCgpIik7CiAJCQkJfQpAQCAtMjA2LDggKzIxMCw4IEBA
CiAJCQlmb3IgKGk9MDsgaTxhcmdjOyBpKyspIHsKIAkJCQlmcCA9IGZvcGVuKGFyZ3ZbaV0sICJy
Iik7CiAJCQkJaWYgKGZwID09IE5VTEwpCi0JCQkJCWVycngoRVhJVF9GQUlMVVJFLCAiJXM6ICVz
OiVzIiwKLQkJCQkJICAgICBnZXRwcm9nbmFtZSgpLCBhcmd2W2ldLAorCQkJCQllcnJ4KEVYSVRf
RkFJTFVSRSwgIiVzOiAlcyIsCisJCQkJCSAgICAgYXJndltpXSwKIAkJCQkJICAgICBzdHJlcnJv
cihlcnJubykpOwogCQkJCWRvX2NvbnYoYXJndltpXSwgZnAsIG9wdF9mLCBvcHRfdCwgb3B0X3Ms
CiAJCQkJCW9wdF9jKTsK

--Multipart=_Sun__24_Apr_2005_08_09_19_-0400_0mkPq3wCK68V6G1J--