Skip to Content.
Sympa Menu

freetds - Re: killer query

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Bill Thompson" <thompbil AT exchange.uk.ml.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: killer query
  • Date: Wed, 26 Jun 2002 06:13:16 -0400


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




Archive powered by MHonArc 2.6.24.

Top of Page