FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Hmmm...

Whoever (don't think it was me...the variable names aren't my style)
wrote this should have used TDS_INT and TDS_FLOAT...that will resolve the
problem once I make the changes mentioned in my other email.

Brian

On Thu, 25 Jan 2001, Steve Langasek wrote:

> Hi Brian,
> 
> On Wed, 24 Jan 2001, Brian Bruns wrote:
> 
> > Technically it is defined by the API as length of dest, I don't have the
> > doc in front of me but I believe it is something like 'size of buffer
> > into which the data will be copied' (remember that tds_convert is called
> > by dbconvert, ct_convert and implicitly by binding a to a different type).
> 
> > So there is an off by one error, and I'll apply the patch.

> 
> At the bottom is a patch that addresses all of the off-by-one errors I found
> in tds/convert.c.  In addition, it ensures that all SYBTEXT and SYBCHAR
> targets are null-terminated strings, which if I understand correctly is the
> proper behavior.
> 
> I also noticed these lines during the process:
> 
> TDS_INT tds_convert_money(int srctype,unsigned char *src,
>         int desttype,unsigned char *dest,TDS_INT destlen)
> {
> long high;
> unsigned long low;
> double dmoney;
> 
> ...
> 
>                 case SYBFLT8:
>                         /* Used memcpy to avoid alignment/bus errors */
>                         memcpy(&high, src, 4);
>                         memcpy(&low, src+4, 4);
>                         dmoney = (double)high * 65536 * 65536 + (double)low;
>                         dmoney = dmoney / 10000;
>                         *(double *)dest = dmoney;
>                         break;  
> 
> I don't have a patch for this yet, but just as a heads-up, this behavior is
> not endian-clean on machines with a 64-bit word.  Since a long int is 8 
> bytes
> long on alpha, ppc, etc., these memcpy's only write to the first 4 bytes of
> the long... and those first 4 bytes aren't guaranteed to be the low bytes
> we're looking for.
>