FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Bill,

TDS 7 is little endian only, so there would be no swapping of bytes.  True 
this is only valid for direct manipulation of the TDS_UNIQUE structure.  
The way to deal with this would be to implement the byte swap code for 
TDS_UNIQUE in tds_swap_datatype().  Given that SYBUNIQUE -> SYBCHAR 
(currenly) relies on the byte order being little endian, does any of this 
matter?  If anyone can show me any code that directly manipulates 
SYBUNIQUE then I think a patch is appropriate, otherwise let's let it be.

Given that SYBUNIQUE is not part of the original spec no programs should 
be doing anything with it other than binding as char.  But again, if there 
is any reason to treat TDS_UNIQUE as anything other than opaque, we should 
fix it.

Brian

On Wed, 26 Jun 2002, Bill Thompson wrote:

> Phew! well it sounds like you understand this stuff better than I...
> But a couple of points and clarifications...
> 
> > src is a TDS_CHAR* (a raw pointer) and you copy it in a structure. If
> > structure is byte to byte the same you copy correctly data but on 
> > different
> > architectures this fail.
> 
> But this code can only get executed if src points to a TDS_UNIQUE
> structure, so we'll always be copying like to like, no ?
> 
> > Consider this structure:
> > 
> > typedef struct Test
> > {
> >     TDS_INT num;
> > } Test;
> > 
> > and following octets (assuming TDS_INT 32bit):
> > *src = 01 02 03 04 (not C code...)
> > doing 
> > Test tst;
> > memcpy(&tst, src, sizeof(tst));
> > Will produce tst.num == 0x4030201 on little endian machine (such as intel)
> > and tst.num == 0x1020304 on big endian machine (such as sparc).
> 
> Well, yes, but that's not the situation here. Basically this code can only
> get executed if the calling program is asking to convert a TDS_UNIQUE to a
> TDS_UNIQUE. If the source TDS_UNIQUE was received from the server, it's
> already been byte swapped (if necessary) to the clients endian type.
> 
> > Also in some architecture you can have TDS_INT 64bit (alpha) having 
> > garbage
> > and other problems...
> > 
> 
> I'll take your word for it...
> 
> > Best solution is to build structure, such as
> > 
> > tst.num = src[0] | (src[1] << 8) | (src[2] << 16) | (src[3] << 24);
> > 
> > (a macro/inline function and some optimization for every platform is
> > preferred)
> > This should work on every architecture (even quantic, where machine do not
> > handle bit very simply)
> > 
> 
> Well maybe, but again given the only possible circumstances in which this
> code can be called, I don't think it's necessary...
> 
> Bill
>