FreeTDS Development Group

["Eric Deutsch" <edeutsch AT systemsbiology.org>]

The saga continues... more interspersed comments...

> -----Original Message-----
> From: Lowden, James K [mailto:LowdenJK AT bernstein.com]
> Sent: Tuesday, July 09, 2002 11:34 AM
> To: TDS Development Group
> Subject: [freetds] RE: Losing last character of TEXT fields
> 
> > Errr.. I think you may be right.  I changed my code to now read:
> >
> >       case SYBTEXT:
> >       case SYBCHAR:
> >          cplen = srclen > destlen ? destlen : srclen;
> >          memcpy(dest, src, cplen);
> >          return cplen;
> >       case SYBBINARY:
> >          cplen = srclen > destlen ? destlen : srclen;
> >          memcpy(dest, src, cplen);
> >          return cplen;
> >
> > and it seems to work fine.  So perhaps the real question is,
> > why were we ever fooling around with \0 termination in the first
place?
> 
> For someone who doesn't "understand the deeper issues", you're sure
moving
> this along.  ;)

or at least making a pest of myself!

> Thing is, destlen can be negative, and if it is -- and desttype is
SYBCHAR
> -- we null terminate:
> 
> <MS doc>
> destlen
> 
> Is the length, in bytes, of the destination variable. This length is
used
> for the following desttype data type tokens:
> SQLCHAR, SQLVARCHAR, SQLTEXT
> SQLBINARY, SQLVARBINARY, SQLIMAGE
> SQLINTN, SQLFLTN, SQLMONEYN, SQLDATETIMN
> 
> The destlen is ignored for all fixed-length, non-NULL data types.
> 
> When dest points to a DBCHAR string or a DBBINARY array, the value of
> destlen must be the total length of the destination buffer space, or
-1 to
> indicate that there is sufficient space available. Note that when dest
> points to a DBCHAR string, a destlen of -1 causes the character string
to
> be
> given a terminating null.
> </doc>

no fair reading the documentation. ;-)

> I think this would work better:
> 
>       if (destlen > 0) memset (dest, ' ', destlen); // see below
> 
>       case SYBCHAR:
>          if (destlen == -1) {
>             memcpy(dest, src, srclen);
>             dest[srclen++] = '\0';
>             return srclen;
>          }
>          /* else fall through */
>       case SYBTEXT:
>       case SYBBINARY:
>          cplen = srclen < destlen ? srclen : destlen;
>          memcpy(dest, src, cplen);
>          return cplen;
> 
> I think reversing the sense aids clarity, but I wouldn't insist.)
Wanna
> give that a go?

Sure, I can plug it in, but I only ever see SYBTEXT in this function in
my test cases, which yields the same as what I had, so I can't test
properly.  I do not understand why only SYBCHAR gets the special
treatment.

I'm also a little bothered by the space blanking.  It seems like it
might be a significant performance hit if TEXTSIZE is large.  I don't
understand why it should be necessary, too.  But I can be quiet.

> That would penalize someone who passed a destlen < -1 (because cplen
would
> be interpreted as an enormous unsigned integer).  We could say "if
> (destlen
> < 0)", but that would reward them.  <shrug>
> 
> I just read Michael's message.  I think the ct-lib decisions need to
be
> made
> in ct-lib, and a destination length set accordingly when calling
> tds_convert.  That would be the case with dbbind() as well.  By
> initializing
> the buffer to blanks, returning the true length, and null terminating
only
> when necessary, I think we address all permutations.
> 
> Who knew 10 lines could be so worked over?
> 
> --jkl
> 
> ---
> You are currently subscribed to freetds as:
[edeutsch AT systemsbiology.org]
> To unsubscribe, forward this message to leave-freetds-
> 127899P AT franklin.oit.unc.edu