FreeTDS Development Group

["Bill Thompson" <thompbil AT exchange.uk.ml.com>]

> All, 
> 
> The code:
> 
> DBINT dbconvert(DBPROCESS *dbproc,
>                 int srctype,
>                 BYTE *src,
>                 DBINT srclen,
>                 int desttype,
>                 BYTE *dest,
>                 DBINT destlen)
> {
> TDSSOCKET *tds = NULL;
> 
>         if (dbproc) {
>                 tds = (TDSSOCKET *) dbproc->tds_socket;
>         }
> 
>         if (srclen==-1) srclen = strlen((char *)src);
>         return tds_convert(g_tds_context->locale, srctype, (TDS_CHAR *)src,
> srclen, desttype, (TDS_CHAR *)dest, destlen);
> }
> 
> Bug 1:  for fixed-length datatypes,  srclen should be ignored, and in any
> case we shouldn't attempt a strlen on anything not a string.  Test should
> be:
> 
>       if (srclen==-1) {
>               switch(srctype) {
>                 case SYBCHAR:
>                 case SYBVARCHAR:
>                 /* case SYBTEXT:  ?? */
>                               srclen = strlen((char *)src);
>                         break;
>                       default: 
>                               break;
>               }
>       }
> 

Agreed - the sybase manual states:

"srclen - The length, in bytes, of the data to be converted. If the srclen
is 0, the source data is assumed to be null and dbconvert will place an
appropriate null value in the destination variable. Otherwise, this length
is ignored for all datatypes except char, text, binary, and image. For
SYBCHAR, SYBBOUNDARY, and SYBSENSITIVITY data, a length of -1 indicates
that the string is null-terminated. You can use dbdatlen to get the length
of the server data."

This indicates srclen of -1 is only valid for the types stated... 


> Bug 2:  I don't see what tds is doing for us.  Perhaps the computer is
> curious?    
> 

You'll find this is a hangover of one of my fixes (to do with date string
handling) that you initially committed but then reworked with your
strftime/locale fix. Get rid.

> Bug 3:  Because tds_convert has no dbproc, it can't call the proc's error
> handler.  There are many many places it should call the error handler:
> buffer overflows, null destination pointers, inconvertibility.  This touches
> on Frediano's #578095, and is too big a problem, unfortunately, to deal with
> in 0.60.  

Agreed. I think more of the convert code needs to be in the dblib "layer"
.

> 
> --jkl