Re: UCS-2 in gunicode.h

[Derek Simkowiak <dereks kd-dev com>]

-> Dan Winship <danw@helixcode.com> writes: 
-> > iconv returning EINVAL is not a "should not ever happen". As you said
-> > in an earlier message:
-> 
-> OK, so bytes_converted should be set to zero in that case, I guess.

	I count three possible error conditions in g_error():

1) EINVAL from iconv, meaning the charset requested is unsupported.  
Could easily happen in a web/email app (such as the klingon example :).

2) Number of bytes_converted != strlen(inbuf), meaning there was invalid
input encountered during a conversion, and there was only partial success.

3) Something that should "never" happen, i.e. the g_warning ("iconv()
failed: %s", strerror (errno));  errors and the iconv_open/close()
errors.  (There is also a g_malloc() in there that should be tested for
success, but is not)


	Let's compare this to iconv.  The iconv man page lists four
reasons that a conversion will stop:

1.  Invalid multibyte input in the middle of the input string, corresponds
to (2) above

2.  Your done.  (A 100% success condition)

3.  Invalid multibyte input at the end of the input string, also
corresponds to (2) above (I think)

4.  E2BIG, which g_convert() wonderfully handles by automatically growing
the buffer for us before returning it, so this is not an "error" in
g_convert().


-> Maybe we should have a GError?	

	I believe that having bytes_converted be zero for the EINVAL case
is sufficient, that bytes_converted will let you look for any other
convesion-time or input errors, that all the other errors are
memory-allocation related (and thus should produce g_warnings).

	Basically, we need to decide if we want to distinguish between
"charset unsupported" errors and "invalid input" errors.  If we do, we
need a GError (or some other such mechanism).


--Derek	

P.S.> I can see the utility in knowing whether or not the "charset
unsupported" was encountered, but I am scared of GError (don't understand
it)