freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Lowden, James K" <LowdenJK AT bernstein.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: RE: [freetds] Data conversion limit for strings
- Date: Mon, 26 Jan 2004 11:55:40 -0500
> From: ZIGLIO, Frediano, VF-IT [mailto:Frediano.Ziglio AT vodafone.com]
> Sent: January 26, 2004 11:14 AM
>
> You are right however for 0.62 is better to have less changes, just to
> avoid other possible bugs. Also in read.c (read_and_convert) we have
> similar code but we test just EILSEQ and stop if there are no
> conversions.
> Thinking about tds_iconv suppress was introduced to avoid double
> messages so it seems correct to return failure on EINVAL.
One of us is confused. :-)
EINVAL signifies an incomplete sequence at the end of the input buffer.
Because we arbitrarily carve the input into 128-byte chunks, we know that
UTF-8 characters my be sliced in two at the boundary. We should expect
tds_iconv() to return EINVAL; we'll provide the rest of the sequence on the
next call. Part of the purpose of the suppress field was to avoid any
message for conditions the caller would handle.
As I said, though, the logic suboptimal. There's no reason to carve up the
input buffer. We can let tds_iconv() try to fill the output buffer and, if
it runs out of room (E2BIG), flush the output and continue. That way, EILSEQ
and EINVAL become real errors, and E2BIG is suppressed.
In tds_put_string(), we don't return immediately on, say, EILSEQ, but the
effect is the same. On the next iteration of the loop after EILSEQ, no bytes
will be converted, poutbuf == outbuf, and we exit the loop (and procedure).
In both tds_put_string() and read_and_convert(), we convert as much as we
can, emitting an error message in the event we're unable to finish the job.
That's roughly the same behavior an application would see if the conversion
were done on the server (a la Sybase). I'm not sure what return code the
application should see. For example, does dbsqlexec() return FAIL if Sybase
can't convert the string?
--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.
If you, as an intended recipient of this commercial e-mail or advertisement,
would not like to receive further e-mail correspondence from the sender,
please "reply" to the sender indicating your wishes.
In the U.S.: 1345 Avenue of the Americas, New York, NY 10105
-
[freetds] Data conversion limit for strings,
Marco Brinkmann, 01/24/2004
- Re: [freetds] Data conversion limit for strings, James K. Lowden, 01/24/2004
- <Possible follow-up(s)>
-
Re: [freetds] Data conversion limit for strings,
Marco Brinkmann, 01/25/2004
- Re: [freetds] Data conversion limit for strings, James K. Lowden, 01/25/2004
- RE: [freetds] Data conversion limit for strings, ZIGLIO, Frediano, VF-IT, 01/26/2004
- Re: Re: [freetds] Data conversion limit for strings, Marco Brinkmann, 01/26/2004
-
RE: Re: [freetds] Data conversion limit for strings,
ZIGLIO, Frediano, VF-IT, 01/26/2004
- Re: [freetds] Data conversion limit for strings, James K. Lowden, 01/26/2004
- RE: [freetds] Data conversion limit for strings, ZIGLIO, Frediano, VF-IT, 01/26/2004
- RE: [freetds] Data conversion limit for strings, Lowden, James K, 01/26/2004
Archive powered by MHonArc 2.6.24.